Mano colocando una carpeta con el plan de tratamiento de riesgos sobre un escritorio

El tratamiento de riesgos en ISO 27001 es el proceso formal definido en la Cláusula 6.1.3 de la norma, mediante el cual su organización selecciona e implementa controles para abordar cada riesgo de seguridad de la información identificado. Los auditores, tanto en la Fase 1 como en la Fase 2, esperan encontrar una cadena documentada y trazable desde cada riesgo del registro hasta la decisión de tratamiento, los controles identificados, un responsable, una fecha objetivo y evidencia de que el trabajo se llevó a cabo.

Antes de continuar, verifique estos cinco elementos para cada riesgo que supere su umbral de aceptación:

Decisión de tratamiento registrada: evitar, mitigar, transferir o aceptar — indicada de forma explícita, no implícita.
Propietario del riesgo identificado: una persona concreta (no un equipo o departamento) que haya asumido formalmente la responsabilidad.
Controles mapeados al Annex A: cada acción de mitigación referencia el número o números de control del Annex A correspondientes, o justifica un control personalizado.
Fechas objetivo de finalización: realistas, documentadas y que no estén ya vencidas.
Evidencia identificada: el artefacto que demostrará que el control está implementado (incidencia, informe de prueba, contrato, registro de formación).

Si alguno de estos cinco elementos falta para un riesgo que supera el umbral, tiene una no conformidad de auditoría esperando a materializarse.

Conclusiones clave

Un tratamiento de riesgos ISO 27001 eficaz requiere una cadena documentada y trazable desde cada riesgo hasta la decisión de tratamiento, los controles identificados, un responsable, la evidencia y la puntuación residual, todo ello reconciliado en una Declaración de Aplicabilidad (SoA) actualizada.

Punto	Detalles
La Cláusula 6.1.3 define el requisito	El tratamiento debe generar un Plan de Tratamiento de Riesgos (RTP) documentado, una SoA y la aceptación formal del riesgo residual por parte de los propietarios identificados.
Cuatro opciones, cada una con requisitos de evidencia	Evitar, mitigar, transferir y aceptar requieren documentación específica; la aceptación sin un registro firmado por el propietario no supera la auditoría.
La SoA y el RTP deben estar reconciliados	Cada control del Annex A incluido necesita una acción correspondiente en el RTP; cada acción del RTP necesita una referencia al Annex A o un control personalizado justificado.
Las puntuaciones residuales no son negociables	Una columna de puntuación residual en blanco es una de las no conformidades más frecuentes en la Fase 2; vuelva a puntuar cada riesgo tras la implementación.
Ismscalculator acelera la configuración del RTP	La verificación de preparación gratuita y la evaluación completa generan filas estructuradas para el RTP, mapeos del Annex A y una exportación Gantt calibrada según el tamaño y el sector de su organización.

Índice de contenidos

¿Por qué ISO 27001 exige el tratamiento de riesgos y qué exige realmente la Cláusula 6.1.3?
¿Cuáles son las cuatro opciones de tratamiento de riesgos en ISO 27001?
¿Cómo funciona el proceso de tratamiento de riesgos de ISO 27001 paso a paso?
¿Cómo se elabora un Plan de Tratamiento de Riesgos listo para auditoría?
¿Cómo se mapean los tratamientos de riesgos al Annex A y se elabora la SoA?
¿Qué evidencia esperan los auditores de su proceso de seguimiento y revisión?
¿Qué errores cometen los equipos en el tratamiento de riesgos y cómo se corrigen?
¿Cómo ayuda Ismscalculator a dimensionar el esfuerzo y generar un RTP listo para auditoría?
¿Qué criterios se deben usar para seleccionar una opción de tratamiento más allá de los cuatro tipos estándar?
¿Cómo varía el tratamiento de riesgos según el sector y el tamaño de la organización?
Por qué la comunicación y la formación no son opcionales en el tratamiento de riesgos
Qué elogian y qué señalan sistemáticamente los auditores en los Planes de Tratamiento de Riesgos
Ismscalculator le proporciona un punto de partida estructurado para su RTP
Fuentes

¿Por qué ISO 27001 exige el tratamiento de riesgos y qué exige realmente la Cláusula 6.1.3?

ISO/IEC 27001:2022 define un sistema de gestión de seguridad de la información (SGSI) y exige un enfoque basado en riesgos adaptado al contexto, tamaño y objetivos propios de la organización. La norma es deliberadamente no prescriptiva: indica qué hacer, no exactamente cómo hacerlo. Esta flexibilidad es una característica, no una laguna, pero significa que los auditores juzgan su proceso conforme a su propia justificación documentada.

La secuencia de cláusulas es importante. La Cláusula 6.1.2 exige un proceso de evaluación de riesgos documentado que produzca un registro de riesgos con puntuaciones. La Cláusula 6.1.3 parte de ahí y le exige:

Seleccionar opciones de tratamiento para cada riesgo.
Determinar los controles necesarios para implementar dichas opciones.
Comparar los controles elegidos con el Annex A para verificar que no se haya omitido nada necesario.
Elaborar una Declaración de Aplicabilidad (SoA) que enumere todos los controles del Annex A, indique si aplican y justifique la decisión en ambos casos.
Formular un Plan de Tratamiento de Riesgos (RTP) que documente las acciones, responsables, fechas y evidencias previstas.
Obtener la aceptación formal del riesgo residual por parte de los propietarios del riesgo identificados.

La Cláusula 8.2 exige realizar la evaluación de riesgos a intervalos planificados o cuando se produzcan cambios significativos. La Cláusula 8.3 exige implementar el plan de tratamiento de riesgos. Estas dos cláusulas son donde los auditores buscan evidencia de que el plan se ejecutó realmente, no solo que se redactó.

Qué verifican los auditores en la Fase 1 y la Fase 2:

Existe un registro de riesgos y cada entrada tiene una puntuación, una decisión de tratamiento y un responsable.
El RTP referencia controles específicos del Annex A por número y está mapeado a la SoA.
La SoA contempla todos los controles del Annex A de la edición 2022 con una justificación de inclusión o exclusión.
Las puntuaciones de riesgo residual aparecen después del tratamiento, no solo antes.
Los propietarios del riesgo han firmado por escrito la aceptación del riesgo residual.
Los artefactos de evidencia están identificados, son recuperables y están fechados.

Una puntuación residual ausente o una SoA que marca un control como «aplicable» pero el RTP no tiene ninguna acción correspondiente son las dos no conformidades más frecuentes en la Fase 2.

¿Cuáles son las cuatro opciones de tratamiento de riesgos en ISO 27001?

La norma reconoce cuatro opciones de tratamiento. Elegir la correcta para cada riesgo es una decisión de criterio, pero debe ser una decisión documentada y defendible.

Evitar (eliminar el riesgo): Cese la actividad que genera el riesgo. Una empresa que decide no almacenar datos de tarjetas de pago evita por completo los riesgos relacionados con PCI. Los auditores esperan ver una decisión documentada y evidencia de que la actividad se interrumpió. Esta opción suele infrautilizarse porque parece una renuncia a capacidad operativa, pero para riesgos con puntuaciones intrínsecas muy elevadas y ningún beneficio empresarial proporcional, es la solución más limpia.

Mitigar (reducir el riesgo): Aplique controles para reducir la probabilidad o el impacto. Es la opción más habitual y la que genera más entradas en el RTP. Ejemplos: desplegar autenticación multifactor (MFA) para reducir la probabilidad de acceso no autorizado, o cifrar los datos en reposo para reducir el impacto de una brecha. Cada acción de mitigación necesita una referencia específica al Annex A.

Transferir (compartir el riesgo): Traslade las consecuencias financieras u operativas a un tercero, habitualmente mediante un ciberseguro o una cláusula de indemnización contractual con un proveedor. La transferencia no elimina el riesgo; cambia quién asume el coste. Los auditores solicitarán el certificado del seguro o la cláusula contractual como evidencia. La transferencia es adecuada cuando el coste de la mitigación supera la pérdida esperada y existe una contraparte dispuesta a asumirlo.

Aceptar (retener el riesgo): Reconozca formalmente que el riesgo se encuentra dentro del apetito de riesgo de su organización y que no se requiere ningún tratamiento adicional. La aceptación exige la firma escrita de un propietario identificado. Los auditores señalan las entradas de aceptación que carecen de firma o que aceptan riesgos con puntuaciones muy por encima del umbral de aceptación declarado sin explicación.

Factores de decisión y comparativa rápida

Opción de tratamiento	Mejor adecuación	Evidencia requerida por el auditor	Riesgo principal
Evitar	Puntuación intrínseca alta, bajo valor empresarial de la actividad	Decisión documentada, prueba de que la actividad cesó	Pérdida de capacidad empresarial
Mitigar	La mayoría de los riesgos operativos; coste del control proporcional	Mapeo al Annex A, evidencia de implementación, puntuación residual	Implementación incompleta
Transferir	Eventos de alto impacto y baja frecuencia; mercado asegurador disponible	Póliza/contrato con cobertura confirmada	Brechas residuales no cubiertas por la póliza
Aceptar	Riesgos con puntuación baja dentro del apetito declarado	Firma del propietario identificado, registro de aceptación fechado	Acumulación silenciosa de aceptaciones con el tiempo

Los factores de decisión más allá de las cuatro opciones incluyen: el apetito de riesgo documentado de su organización (establecido por la dirección en la Cláusula 5.2), las obligaciones legales o contractuales que pueden exigir controles específicos independientemente de la puntuación del riesgo, el análisis coste-beneficio que compara el coste del control con la reducción esperada de pérdidas, y la viabilidad operativa del control en su entorno.

¿Cómo funciona el proceso de tratamiento de riesgos de ISO 27001 paso a paso?

El proceso es secuencial y cada paso produce una salida documentada. Omitir un paso no ahorra tiempo; crea una laguna que un auditor encontrará.

Complete la evaluación de riesgos (Cláusula 6.1.2). Puntúe cada riesgo en función de la probabilidad y el impacto utilizando su metodología documentada. Elabore un registro de riesgos con puntuaciones intrínsecas. Este es el insumo para el tratamiento.
Aplique sus criterios de aceptación de riesgos. Separe los riesgos que superan el umbral de aceptación de los que están por debajo. Los riesgos por debajo del umbral pueden aceptarse en el registro sin una entrada completa en el RTP. Los riesgos por encima del umbral requieren tratamiento.
Seleccione una opción de tratamiento para cada riesgo que supere el umbral (Cláusula 6.1.3). Documente la justificación. «Elegimos la mitigación porque el coste del control es inferior a la pérdida anual esperada» es auditable. «Elegimos la mitigación» no lo es.
Determine los controles específicos y mapéelos al Annex A. Para cada acción de mitigación, identifique el control o controles del Annex A que satisface. Utilice la referencia de controles del Annex A de ISO 27001 para confirmar que no ha omitido ningún control relevante. Si necesita un control que no figura en el Annex A, documéntelo y justifique por qué es necesario.
Genere la Declaración de Aplicabilidad. Todos los controles del Annex A deben aparecer en la SoA. Para cada uno: indique si está incluido o excluido, vincúlelo al riesgo o requisito legal que justifica su inclusión y, en el caso de las exclusiones, confirme que ningún riesgo del registro quedaría sin atención.
Elabore el Plan de Tratamiento de Riesgos. Asigne propietarios, establezca fechas objetivo e identifique el artefacto de evidencia para cada acción. Las plantillas de profesionales tratan el RTP como un miniproyecto con campos para la acción, el responsable, las fechas de inicio y fin, el estado, la evidencia y la puntuación residual.
Implemente el plan (Cláusula 8.3). Ejecute las acciones. Recopile y almacene la evidencia a medida que avanza, no de forma retroactiva.
Puntúe el riesgo residual. Tras la implementación, vuelva a puntuar cada riesgo. La puntuación residual debe reflejar el estado real de los controles, no el estado deseado.
Obtenga la aceptación formal del riesgo. Los propietarios del riesgo dan su conformidad sobre el riesgo residual. Esto puede ser una firma digital en el documento del RTP, una decisión registrada en la revisión por la dirección o un formulario formal de aceptación.
Revise a intervalos planificados (Cláusula 8.2). Reevalúe cuando se produzcan cambios significativos y al menos anualmente. Actualice el RTP y la SoA en consecuencia.

Quién hace qué: roles y responsabilidades

Rol	Responsabilidades
Responsable del SGSI	Es el propietario del proceso; mantiene el registro de riesgos, el RTP y la SoA; coordina las revisiones
Propietario del riesgo	Responsable del tratamiento de los riesgos asignados; firma la aceptación del riesgo residual
Responsable de TI	Implementa los controles técnicos; aporta la evidencia (incidencias, resultados de pruebas)
Legal / Cumplimiento normativo	Revisa las obligaciones contractuales y regulatorias que afectan a las decisiones de tratamiento
Alta dirección / Consejo de administración	Establece el apetito de riesgo; revisa y aprueba el RTP en la revisión por la dirección (Cláusula 9.3)

Escale a la dirección cuando un riesgo que supera el umbral no pueda tratarse dentro del presupuesto, cuando una decisión de tratamiento requiera aceptar un riesgo que supera el apetito declarado, o cuando surja un nuevo riesgo derivado de un cambio organizativo significativo.

¿Cómo se elabora un Plan de Tratamiento de Riesgos listo para auditoría?

El RTP no es una hoja de cálculo que se rellena una vez y se archiva. Los auditores lo tratan como un documento vivo y comprobarán el historial de versiones, las fechas de aprobación y si los enlaces a la evidencia son reales y recuperables.

Campos obligatorios para cada entrada del RTP

Cada fila de su RTP debe contener:

ID del riesgo: coincide exactamente con la entrada del registro de riesgos.
Descripción del riesgo: una frase que describe la amenaza, la vulnerabilidad y el impacto potencial.
Puntuación del riesgo intrínseco: probabilidad × impacto antes de los controles.
Decisión de tratamiento: evitar, mitigar, transferir o aceptar.
Acciones específicas: pasos concretos y verificables (no «mejorar la seguridad» — véase la sección de errores más abajo).
Referencia(s) al control del Annex A: el número o números de control de la edición 2022.
Propietario del riesgo: persona identificada nominalmente.
Fechas de inicio y de finalización objetivo.
Artefacto de evidencia: el documento, incidencia o registro específico que acredita la finalización.
Puntuación del riesgo residual: puntuada de nuevo tras la implementación.
Firma de aceptación: nombre, fecha y método de firma.

Ejemplo de entrada en el RTP

Campo	Valor de ejemplo
ID del riesgo	R-014
Descripción del riesgo	Una cuenta de administrador con privilegios sin MFA podría verse comprometida, exponiendo todos los datos de producción
Puntuación intrínseca	16
Decisión de tratamiento	Mitigar
Acciones específicas	Desplegar MFA para todas las cuentas de administrador a través de Okta; revisar y eliminar cuentas con privilegios inactivas trimestralmente
Referencia al Annex A	A.8.2 (Derechos de acceso privilegiado), A.9.4 (Autenticación segura)
Propietario del riesgo	Jane Smith, Directora de TI
Fecha objetivo de finalización	31 de marzo de 2026
Artefacto de evidencia	Incidencia de despliegue de MFA en Okta; informe de revisión de accesos trimestral
Puntuación residual	6 (probabilidad 2 × impacto 3)
Firma de aceptación	Jane Smith, firmado el 31 de marzo de 2026

Las guías de profesionales recomiendan un umbral de puntuación de aproximadamente 10 o superior para generar una entrada independiente en el RTP. Los riesgos por debajo de ese umbral pueden anotarse en el registro de riesgos con una breve justificación del tratamiento y aceptarse sin una fila completa en el RTP.

Control de versiones y aprobación: feche cada versión del RTP, registre quién la aprobó y conserve las versiones anteriores. Los auditores a veces solicitan ver la versión anterior para confirmar que el plan se actualizó tras un ciclo de revisión, no justo antes de la auditoría.

¿Cómo se mapean los tratamientos de riesgos al Annex A y se elabora la SoA?

La SoA es el documento que lo une todo. Es también el documento en el que los auditores pasan más tiempo durante la Fase 2, porque es el único lugar donde las decisiones de tratamiento, las selecciones de controles y las justificaciones de exclusión deben ser coherentes con el RTP y el registro de riesgos.

La edición 2022 de ISO 27001 reorganizó el Annex A en 93 controles distribuidos en cuatro temáticas: organizativos, de personas, físicos y tecnológicos. Cada uno de esos 93 controles debe aparecer en su SoA con un estado claro de inclusión o exclusión.

Ejemplos de filas de mapeo en la SoA

Justificar las exclusiones es donde muchas organizaciones tienen dificultades. «No aplicable» no es una justificación. La SoA debe explicar por qué el control no aplica: la organización no dispone de los activos relevantes, la amenaza no existe en el contexto operativo, o un control compensatorio aborda el mismo riesgo. Un auditor que encuentre un riesgo en el registro que un control supuestamente excluido abordaría levantará una no conformidad de inmediato.

La orientación de ISO confirma que el Annex A no es exhaustivo. Si su evaluación de riesgos identifica una amenaza que ningún control del Annex A aborda directamente, puede diseñar un control personalizado. Documéntelo en la SoA como un control adicional con una justificación clara.

Lista de verificación de reconciliación que los auditores comprobarán:

Cada acción del RTP referencia al menos un número de control del Annex A.
Cada control del Annex A marcado como «incluido» en la SoA tiene al menos una acción correspondiente en el RTP o una entrada en el registro de riesgos.
Ningún control del Annex A está marcado como «excluido» si un riesgo del registro lo requeriría.
Los controles personalizados más allá del Annex A están documentados con una justificación.
La fecha de versión de la SoA coincide con la última actualización del RTP o es posterior a ella.

Consejo profesional: Numere las filas de su SoA de forma que coincidan exactamente con los números de control del Annex A (A.5.1 hasta A.8.34 en la edición 2022). Los auditores trabajan a partir de la norma; una SoA que utilice la misma numeración les permite hacer referencias cruzadas en minutos, en lugar de buscar a través de un formato personalizado.

¿Qué evidencia esperan los auditores de su proceso de seguimiento y revisión?

Un RTP completado no es el final del proceso. Los auditores quieren ver que el SGSI está en funcionamiento, no solo documentado. La biblioteca de evidencias que construya durante la implementación es lo que sobrevive al muestreo de la auditoría.

Cadencia de revisión según la gravedad del riesgo

Riesgos críticos y altos (puntuación superior a 15): revisión mensual hasta que la puntuación residual caiga por debajo del umbral; después, trimestral.
Riesgos medios (puntuación entre 8 y 15): revisión trimestral.
Riesgos bajos (puntuación inferior a 8): revisión anual, o en la próxima revisión por la dirección programada.
Desencadenantes ad hoc: cambio organizativo significativo (nuevo sistema, adquisición, cambio relevante en procesos), un incidente de seguridad, un casi-accidente o un cambio en el panorama de amenazas.

Lista de verificación de evidencias para cada tratamiento completado

Incidencia de gestión del cambio o tarea de proyecto que demuestre que la acción se completó.
Resultado de prueba técnica o informe de configuración (para controles técnicos).
Registros de finalización de formación (para controles de personas).
Contrato o certificado de seguro (para decisiones de transferencia).
Informe de prueba de copia de seguridad o restauración (para controles de disponibilidad).
Actas de la revisión por la dirección que hagan referencia al estado del RTP.
Formulario de aceptación del riesgo residual firmado o registro equivalente.

KPI y registros que los auditores comprueban habitualmente

KPI / Registro	Qué buscan los auditores
Tasa de finalización del tratamiento	Porcentaje de acciones del RTP completadas en la fecha objetivo; los elementos vencidos necesitan explicación
Tendencia del riesgo residual	¿Están disminuyendo las puntuaciones con el tiempo, o los mismos riesgos siguen apareciendo con puntuaciones altas?
Registro de acciones vencidas	Cualquier acción que supere su fecha objetivo sin una prórroga documentada y aprobada por el propietario
Registro de incidentes vs. registro de riesgos	¿Los incidentes se corresponden con riesgos conocidos? Los riesgos no registrados que causaron incidentes son una no conformidad
Registros de revisión por la dirección	Evidencia de que la alta dirección revisó el estado del RTP a intervalos planificados (Cláusula 9.3)

Señales de alerta que generan no conformidades en auditoría: una puntuación de riesgo residual idéntica a la intrínseca (sugiere que los controles no se implementaron realmente), acciones del RTP sin propietario identificado, controles listados como «implementados» en la SoA sin evidencia de respaldo, y actas de revisión por la dirección que no hacen referencia al RTP.

¿Qué errores cometen los equipos en el tratamiento de riesgos y cómo se corrigen?

Los errores más perjudiciales no son técnicos. Son fallos de documentación que hacen invisible el trabajo real para un auditor.

Acciones de tratamiento vagas. «Mejorar los controles de acceso» no es una acción auditable. «Desplegar MFA para todas las cuentas con privilegios de administrador en los sistemas de producción antes del 31 de marzo de 2026, evidenciado mediante el informe de configuración de Okta» sí lo es. Cada acción debe responder: qué exactamente, por quién, para cuándo y cómo se demuestra.

Puntuaciones residuales ausentes. Los auditores lo ven constantemente. El RTP tiene una columna de puntuación intrínseca y una columna de tratamiento, pero la columna de puntuación residual está en blanco o dice «pendiente». Una puntuación residual en blanco significa que no puede demostrar que el control redujo el riesgo, lo que hace inverificable el tratamiento.

SoA y RTP desincronizados. La SoA indica que ciertos controles están incluidos, pero el RTP puede no tener ninguna acción que los implemente; o viceversa. En cualquier caso, la cadena de trazabilidad se rompe y los auditores lo señalarán.

Sin aceptación formal del riesgo. La aceptación es una opción de tratamiento, pero requiere la firma documentada de un propietario identificado. Una entrada que dice «aceptado» sin firma, sin fecha y sin referencia a los criterios de apetito de riesgo no es una aceptación válida.

Aceptación sin fecha de caducidad. La aceptación del riesgo no debería ser permanente por defecto. Establezca una fecha de caducidad (normalmente 12 meses) para que los riesgos aceptados se revisen en el siguiente ciclo en lugar de prorrogarse silenciosamente de forma indefinida.

Consejo profesional: Cree una convención de nomenclatura para los artefactos de evidencia que incluya el ID del riesgo, la referencia al control y la fecha (p. ej., R-014_A8.2_MFA_2026-03-31). Cuando un auditor solicite evidencia de un control específico, podrá recuperarla en segundos en lugar de buscar en una unidad compartida.

Reescriba cada acción de tratamiento para incluir un verbo, un alcance, una fecha y un artefacto de evidencia.
Realice una verificación mensual de reconciliación entre la SoA y el RTP antes de que se abra la ventana de auditoría.
Configure recordatorios en el calendario para las fechas de caducidad de las aceptaciones, de modo que ningún riesgo aceptado supere su fecha de revisión sin ser detectado.
Almacene toda la evidencia en una estructura de carpetas organizada por ID de riesgo, no por control ni por fecha.

¿Cómo ayuda Ismscalculator a dimensionar el esfuerzo y generar un RTP listo para auditoría?

Saber qué documentar es la mitad del problema. Saber cuánto trabajo requerirá y disponer de una estructura para capturarlo es la otra mitad. Ahí es donde Ismscalculator encaja en el proceso.

El flujo de trabajo es sencillo:

Realice la evaluación de preparación gratuita. La autocomprobación de 2 minutos puntúa su madurez actual en las cuatro temáticas de controles del Annex A, incluida la gestión de riesgos. Los riesgos que superan su umbral emergen de inmediato con prioridades de tratamiento sugeridas.
Genere filas del RTP a partir de los resultados de la evaluación. La plataforma genera entradas estructuradas para el RTP con campos prepoblados (descripción del riesgo, referencias al Annex A, acciones sugeridas) que puede editar para adaptarlas a su contexto específico.
Exporte el mapeo de la SoA. La exportación incluye referencias a los controles del Annex A alineadas con sus decisiones de tratamiento, listas para incorporar a su documento de SoA.
Utilice la exportación Gantt para la planificación de plazos. Cada acción del RTP se mapea a una tarea de proyecto con una duración sugerida basada en comparaciones con referencias de referencia para el tamaño y el sector de su organización.
Vincule los elementos exportados a su biblioteca de evidencias. La exportación en PDF incluye marcadores de posición para artefactos (número de incidencia, informe de prueba, fecha de firma) que rellena a medida que avanza la implementación.

Consejo profesional: Utilice las comparaciones con referencias de referencia de Ismscalculator para validar su cronograma de tratamiento frente a dicha referencia antes de presentar el RTP a la dirección. Un plan significativamente más largo o más corto que el de referencia para el tamaño de su sector generará preguntas; tener los datos de referencia listos las responde antes de que se formulen.

La plataforma también ofrece solicitudes de presentación a consultores independientes de ISO 27001 si su equipo necesita una revisión externa del RTP antes de la auditoría de certificación. Para las empresas SaaS y tecnológicas en particular, las plantillas de riesgo específicas para la nube reducen el tiempo necesario para elaborar el registro de riesgos inicial desde cero.

¿Qué criterios se deben usar para seleccionar una opción de tratamiento más allá de los cuatro tipos estándar?

Las cuatro opciones (evitar, mitigar, transferir, aceptar) cubren la mayoría de los escenarios, pero la decisión entre ellas no siempre es obvia. Varios criterios deben orientar la elección de forma sistemática.

Alineación con el apetito de riesgo. El apetito de riesgo documentado de su organización (establecido a nivel del consejo de administración o de la alta dirección) define el límite entre el riesgo residual aceptable e inaceptable. Una opción de tratamiento que deje el riesgo residual por encima del apetito no es una elección válida, independientemente del coste.

Proporcionalidad coste-beneficio. El coste de un control debe ser proporcional al riesgo que aborda. Un coste de control anual de 50.000 € para un riesgo con una pérdida anual esperada de 5.000 € es difícil de justificar, a menos que los requisitos regulatorios lo exijan. Documente el análisis, no solo la conclusión.

Obligaciones legales y contractuales. Algunos controles no son opcionales. HIPAA, PCI-DSS, las leyes estatales de notificación de brechas de datos y los contratos con clientes pueden exigir controles específicos independientemente de su puntuación de riesgo interna. Estas obligaciones prevalecen sobre el cálculo coste-beneficio y deben reflejarse en la SoA como inclusiones legalmente obligatorias.

Viabilidad operativa. Un control que no puede implementarse en su entorno dentro de un plazo realista no es un tratamiento real. Si el control técnicamente correcto no es factible, documente el motivo y seleccione un control compensatorio provisional mientras se planifica la solución a largo plazo.

Tratamientos combinados. Un único riesgo puede tener varias opciones de tratamiento aplicadas simultáneamente. Un riesgo de exposición de datos de un proveedor podría mitigarse parcialmente (cifrado, controles de acceso), transferirse parcialmente (indemnización contractual) y aceptarse el residual. Documente cada componente por separado en el RTP de modo que el efecto combinado sobre la puntuación residual sea trazable.

Objetivo de riesgo residual. Trabaje de forma inversa a partir de la puntuación residual que necesita alcanzar para situar el riesgo dentro del apetito. Si la mitigación por sí sola no puede lograrlo a un coste proporcional, puede ser necesaria la transferencia o un enfoque combinado.

¿Cómo varía el tratamiento de riesgos según el sector y el tamaño de la organización?

El proceso es el mismo; los controles, los umbrales y las evidencias tienen un aspecto muy diferente según el contexto.

Las organizaciones sanitarias se enfrentan a obligaciones derivadas de HIPAA que exigen de facto determinados controles independientemente de la puntuación del riesgo. Un hospital que trata riesgos de exposición de datos de pacientes mitigará típicamente con cifrado (A.8.24), controles de acceso (A.8.2) y registro de auditoría (A.8.15), y transferirá el riesgo residual mediante un seguro de ciberresponsabilidad. La biblioteca de evidencias incluye documentación exigida por HIPAA junto con los artefactos ISO. Para la gestión de riesgos en la nube en finanzas sanitarias, la SoA a menudo abarca más de 80 controles incluidos.

Las entidades de servicios financieros operan bajo requisitos de la SEC, FINRA y normativas estatales que generan inclusiones de controles obligatorias. Los umbrales de aceptación de riesgos tienden a ser más bajos que en otros sectores porque los reguladores esperan un tratamiento activo de la mayoría de los riesgos identificados. Los plazos de tratamiento también son más cortos; una entidad financiera que acepta un riesgo con puntuación alta durante 12 meses sin un plan de tratamiento documentado es probable que atraiga el escrutinio regulatorio antes de que llegue un auditor de ISO.

Las empresas SaaS y tecnológicas a menudo concentran sus riesgos en los dominios de infraestructura cloud y ciclo de vida del desarrollo de software. Las acciones de tratamiento frecuentemente referencian A.8.25 (ciclo de vida de desarrollo seguro), A.8.9 (gestión de la configuración) y A.8.23 (filtrado web). La evidencia suele estar en sistemas de gestión de incidencias como Jira o GitHub, lo que facilita la vinculación de artefactos a las entradas del RTP.

Las pequeñas empresas con menos de 50 empleados pueden simplificar la estructura del RTP sin sacrificar la auditabilidad. Una única hoja de cálculo con los campos requeridos es suficiente; la norma no exige una herramienta o formato específicos. La guía de ISO 27001 para pequeñas empresas recomienda priorizar los 10 principales riesgos por puntuación y tratarlos completamente antes de ampliar el registro. Un auditor que revise un SGSI de una pequeña empresa espera proporcionalidad; un RTP de 200 filas para una empresa de 20 personas suscita preguntas sobre si el proceso está genuinamente gestionado o simplemente documentado.

Los entornos de fabricación y tecnología operacional (OT) introducen riesgos físicos y de proceso que los controles tecnológicos del Annex A no abordan completamente. Los controles personalizados más allá del Annex A son habituales aquí, especialmente para el acceso físico a los sistemas de control (A.7.1, A.7.2) y el riesgo de proveedores (A.5.19, A.5.20). La SoA para un entorno OT incluye típicamente más controles físicos y más adiciones personalizadas que un entorno puramente TI.

¿Cómo varía el tratamiento de riesgos según el sector y el tamaño de la organización? — diagrama de visión general

Por qué la comunicación y la formación no son opcionales en el tratamiento de riesgos

Un Plan de Tratamiento de Riesgos que reside en una unidad compartida y solo conoce el responsable del SGSI no es un SGSI en funcionamiento. Las personas responsables de implementar controles, recopilar evidencias y escalar incidentes necesitan comprender qué están haciendo y por qué.

Mano colocando una carpeta de formación en seguridad sobre una mesa

Concienciación de los propietarios del riesgo. Los propietarios del riesgo que no comprenden su responsabilidad no recopilarán evidencias, no escalarán cuando un tratamiento se retrase y no firmarán los formularios de aceptación del riesgo residual con plena conciencia de lo que están aceptando. Una sesión informativa de 30 minutos al inicio de cada ciclo de tratamiento, centrada en los riesgos específicos del propietario y en la evidencia que debe producir, es más eficaz que un correo electrónico de concienciación en seguridad dirigido a toda la empresa.

Formación para los implementadores de controles. El personal técnico que implementa controles necesita conocer la configuración o el proceso específico requerido, no solo una directriz general. «Activar MFA» produce resultados inconsistentes. Un procedimiento documentado con capturas de pantalla, un protocolo de prueba y un revisor designado produce un resultado auditable.

Comunicación con la dirección. La alta dirección debe recibir actualizaciones sobre el estado del RTP en la revisión por la dirección (Cláusula 9.3). El formato importa: un panel semáforo que muestre la tasa de finalización del tratamiento, las acciones vencidas y la tendencia del riesgo residual comunica más en dos minutos que un informe de 40 páginas. Los auditores solicitarán ver las actas de la revisión por la dirección; esas actas deben hacer referencia a métricas específicas del RTP, no solo confirmar que la reunión tuvo lugar.

Comunicación de cambios. Cuando se produce un cambio organizativo significativo (una nueva plataforma cloud, una fusión, un cambio en las actividades de tratamiento de datos), la evaluación de riesgos y el RTP deben actualizarse. Las personas que tienen conocimiento del cambio —normalmente los gestores de proyectos de TI y los responsables de unidades de negocio— necesitan un canal claro para notificar al responsable del SGSI. Sin ese canal, los riesgos derivados de nuevas actividades no se registran hasta que un incidente o un auditor los descubre.

Los registros de formación son evidencia. Almacene los registros de finalización de la formación de concienciación en seguridad, la formación específica de controles por rol y cualquier ejercicio de simulación en la misma biblioteca de evidencias que sus artefactos técnicos. Los auditores verifican los controles de personas con tanto rigor como los técnicos.

Qué elogian y qué señalan sistemáticamente los auditores en los Planes de Tratamiento de Riesgos

Tres cosas que los auditores comentan positivamente: un registro de riesgos y un RTP que utilizan IDs de riesgo idénticos en todo el documento (sin necesidad de una capa de traducción), puntuaciones residuales visiblemente inferiores a las intrínsecas con una explicación clara de qué controles impulsaron la reducción, y actas de revisión por la dirección que referencian elementos específicos del RTP por ID en lugar de hablar de «riesgos de seguridad» en abstracto.

Tres patrones que generan no conformidades casi siempre: acciones de tratamiento redactadas como intenciones en lugar de trabajo completado («planeamos implementar MFA» en un documento fechado seis meses antes de la auditoría), inclusiones en la SoA sin ninguna acción correspondiente en el RTP ni enlace a evidencia, y entradas de aceptación de riesgos firmadas por alguien que no tiene autoridad para aceptar riesgos en nombre de la organización.

La diferencia entre un RTP que supera la auditoría y uno que la suspende raramente tiene que ver con la calidad de los controles de seguridad. Casi siempre se trata de disciplina en la documentación. Una organización con una seguridad genuinamente buena pero un RTP mal documentado recibirá más no conformidades que una organización con controles mediocres y una documentación meticulosa. Eso no es un defecto del proceso de auditoría; es precisamente el objetivo. La norma exige demostrar que gestiona el riesgo de forma sistemática, y la documentación es la única forma de demostrarlo.

Tres prioridades para cualquier equipo que prepare un RTP para auditoría: cerrar todas las puntuaciones residuales pendientes antes de la ventana de auditoría, reconciliar la SoA y el RTP en una única sesión utilizando la lista de verificación de la sección de mapeo de la SoA anterior, y confirmar que cada propietario del riesgo puede localizar y describir su artefacto de evidencia sin ayuda del responsable del SGSI.

Ismscalculator le proporciona un punto de partida estructurado para su RTP

Elaborar un RTP listo para auditoría desde cero requiere un tiempo que la mayoría de los equipos de cumplimiento normativo no tienen. Ismscalculator reduce el tiempo de configuración al proporcionarle un marco de RTP preestructurado calibrado según el tamaño, el sector y el nivel de madurez actual de su organización, de modo que dedique su tiempo a la sustancia y no al formato.

Ismscalculator

Realice la verificación de preparación gratuita de 2 minutos para obtener una instantánea inmediata de su madurez en el tratamiento de riesgos en las cuatro temáticas de controles de ISO/IEC 27001:2022. A partir de ahí, la evaluación de preparación completa genera filas del RTP con mapeos del Annex A, un cronograma de implementación basado en Gantt y una exportación en PDF que puede compartir con auditores o con la dirección. Las comparaciones con referencias de referencia le permiten validar su cronograma de tratamiento frente a dicha referencia antes de presentarlo. Si desea una revisión independiente antes de su auditoría de certificación, la plataforma puede ponerle en contacto directamente con un consultor de ISO 27001. Sus datos son privados; los resultados son suyos para conservar y editar.

Fuentes

Las siguientes fuentes se utilizaron para elaborar esta guía y merecen guardarse en marcadores para consultar el lenguaje de las cláusulas, la preparación para la auditoría y las plantillas de referencia:

Tratamiento de Riesgos en ISO 27001: Guía Lista para Auditoría