Blog · 10 de octubre de 2026
Riesgo residual en ISO 27001: cómo evaluarlo y aceptarlo
Qué es el riesgo residual en ISO 27001, cómo evaluarlo y quién debe aceptarlo dentro de la organización, con criterio de auditor.
Introducción
El riesgo residual ISO 27001 es el nivel de exposición que permanece después de aplicar controles de seguridad a un escenario de riesgo. No representa un fallo del SGSI ni equivale a que el tratamiento sea insuficiente por definición. Incluso con medidas sólidas, una organización puede seguir expuesta a errores humanos, vulnerabilidades desconocidas, indisponibilidad de terceros o amenazas que evolucionan.
La cuestión útil no es si podemos llevar todos los riesgos a cero. La cuestión es si conocemos con precisión qué riesgo queda, por qué queda, qué evidencia demuestra la eficacia de los controles y quién tiene autoridad para decidir si resulta aceptable.
Tabla De Contenidos
- Cómo Determinar El Riesgo Residual
- Cómo Decidir Si El Riesgo Residual Es Aceptable
- Key Takeaways
- Preguntas Frecuentes
- Conclusión
TL;DR
El riesgo residual es el riesgo que permanece tras el tratamiento. Para gestionarlo conforme a ISO/IEC 27001:2022, debemos reevaluar probabilidad e impacto, comprobar la eficacia real de los controles, compararlo con los criterios de aceptación y dejar una decisión trazable del propietario del riesgo.
Cómo Determinar El Riesgo Residual
La determinación del riesgo residual parte de una evaluación de riesgos consistente. Primero identificamos el activo de información, el escenario de amenaza, la vulnerabilidad explotable, las consecuencias y los controles existentes o previstos. Después valoramos qué cambia realmente tras el tratamiento.
ForensicSpot define el riesgo residual como el que permanece después de aplicar controles y señala que debe valorarse con las escalas de probabilidad e impacto posteriores al tratamiento. Este punto parece sencillo, pero exige evitar un error habitual: asignar una valoración reducida solo porque un control aparece en una política o en un plan de proyecto.
Riesgo Inherente, Riesgo Residual Previsto Y Riesgo Residual Verificado
Conviene distinguir tres momentos de la valoración. Esta separación mejora la calidad de las decisiones y reduce el riesgo de presentar como eficaz un control que todavía no ha demostrado funcionamiento sostenido.
| Momento De La Evaluación | Qué Representa | Base De La Valoración | Uso Principal |
|---|---|---|---|
| Riesgo inherente | Exposición antes de considerar el tratamiento | Amenaza, vulnerabilidad, activo y consecuencias | Priorizar el tratamiento |
| Riesgo residual previsto | Exposición esperada cuando el control esté implantado | Diseño del control, alcance previsto y supuestos | Aprobar el plan de tratamiento |
| Riesgo residual verificado | Exposición observada tras comprobar la operación del control | Registros, pruebas, cobertura, excepciones y resultados | Aceptar, reabrir o escalar el riesgo |
El riesgo residual previsto es válido para planificar, pero no debería confundirse con el riesgo residual verificado. Pensemos en un control de autenticación multifactor para el acceso remoto. Si está aprobado, contratado y configurado para una parte de la plantilla, puede reducir previsiblemente la probabilidad de acceso no autorizado. Sin embargo, mientras existan cuentas excluidas, integraciones sin protección equivalente o registros incompletos, la reducción real no está completamente demostrada.
En ese caso, el registro de riesgos debería reflejar dos datos: el objetivo de riesgo residual tras la implantación y el estado efectivo de la medida. Esta distinción evita que la organización cierre el riesgo antes de tiempo.
Reevaluar Probabilidad E Impacto Sin Convertir La Matriz En Una Ficción
Las escalas de probabilidad e impacto son herramientas de decisión, no mediciones científicas exactas. Una escala de uno a cinco puede ser útil si las definiciones son claras, se aplican de forma consistente y están vinculadas al contexto de negocio. Se vuelve poco fiable cuando cada equipo interpreta los niveles a su manera.
Para valorar la probabilidad residual, podemos revisar si el control reduce la posibilidad de que ocurra el evento. Por ejemplo:
• La gestión de parches puede reducir la ventana de explotación de una vulnerabilidad conocida.
• La segregación de funciones puede reducir la probabilidad de fraude interno no detectado.
• La monitorización de eventos puede no impedir un ataque, pero puede reducir el tiempo hasta su detección.
Para valorar el impacto residual, debemos examinar si el control limita las consecuencias una vez que el evento ocurre:
• Las copias de seguridad probadas pueden reducir el impacto de un ransomware sobre la disponibilidad.
• El cifrado puede reducir el impacto de una pérdida de dispositivos sobre la confidencialidad.
• Un plan de continuidad probado puede reducir la duración de una interrupción crítica.
La transferencia merece un análisis separado. Contratar un proveedor, introducir cláusulas contractuales o adquirir un seguro puede compartir costes o responsabilidades, pero no elimina automáticamente la exposición operativa, regulatoria o reputacional. Si un proveedor de nómina sufre una brecha, la organización que decide los fines y medios del tratamiento puede seguir afrontando obligaciones frente a empleados, clientes o autoridades.
Qué Evidencia Demuestra Que Un Control Reduce El Riesgo
La eficacia del control no se demuestra solo con una política aprobada. Necesitamos evidencia proporcionada al riesgo y al tipo de control. La evidencia en la gestión de riesgos permite conectar la decisión de aceptación con hechos comprobables, no con declaraciones generales.
Para un control técnico, la evidencia puede incluir configuraciones, inventarios de cobertura, registros de ejecución, alertas atendidas, resultados de pruebas y tratamiento de excepciones. Para un control organizativo, puede incluir asignaciones de responsabilidad, registros de formación, revisiones de acceso, actas de comité y resultados de auditoría interna.
Una forma práctica de revisar la eficacia es responder a estas cuatro preguntas:
- ¿El control está diseñado para el escenario concreto? Un antivirus no resuelve por sí solo un riesgo de acceso privilegiado sin supervisión.
- ¿Está implantado en el alcance definido? Debemos identificar activos, sistemas, sedes, procesos o terceros que queden fuera.
- ¿Opera de forma repetible? Un registro aislado no prueba funcionamiento continuo.
- ¿Las excepciones están controladas? Las cuentas de emergencia, dispositivos heredados y proveedores externos suelen concentrar la exposición restante.
PJR explica que el riesgo residual se determina considerando los efectos esperados de las medidas y puede requerir otra iteración de tratamiento. En la práctica, esa nueva iteración resulta especialmente necesaria cuando la cobertura es parcial, el control falla en pruebas o las condiciones del riesgo han cambiado.
Cómo Decidir Si El Riesgo Residual Es Aceptable
Aceptar un riesgo no significa ignorarlo. Significa reconocer que, tras evaluar alternativas razonables, la organización decide asumir una exposición concreta dentro de límites definidos. La diferencia es esencial: una ausencia de tratamiento es una omisión; una aceptación formal es una decisión consciente, atribuida y revisable.
La valoración de riesgos debe estar alineada con criterios aprobados antes de que aparezca la necesidad de justificar una excepción. Si los umbrales se modifican para acomodar un riesgo ya conocido, el proceso pierde independencia y trazabilidad.
Criterios Para Aceptar, Tratar O Escalar
No todos los riesgos cercanos al umbral requieren la misma respuesta. Además de la puntuación, conviene valorar obligaciones legales, compromisos contractuales, concentración de activos críticos, dependencia de terceros y grado de incertidumbre de los datos.
| Situación Del Riesgo Residual | Decisión Habitual | Condición Para Sostener La Decisión |
|---|---|---|
| Dentro del umbral y con controles verificados | Aceptar y revisar periódicamente | Propietario identificado y evidencia suficiente |
| Dentro del umbral, pero con evidencia limitada | Aceptación temporal o seguimiento reforzado | Fecha corta de revisión y plan de validación |
| Por encima del umbral con tratamiento viable | Tratar de nuevo | Responsable, recursos y fecha de cierre definidos |
| Por encima del umbral sin tratamiento razonable inmediato | Escalar para excepción | Autoridad adecuada, justificación y plazo de vigencia |
| Asociado a una obligación no negociable | Evitar, rediseñar o detener la actividad | Evaluación legal, contractual y operativa específica |
Por ejemplo, una empresa puede aceptar temporalmente un riesgo residual medio asociado a una aplicación heredada si existe un plan de sustitución aprobado, segmentación de red, monitorización reforzada y una fecha cierta de retirada. Sería imprudente tratar esa misma situación como aceptable sin plazo, sin responsable y sin evidencia de que la segmentación funciona.
Preeco indica que la aceptación del riesgo residual debe ser consciente, verificable y vinculada a criterios de aceptación definidos. Esta condición protege tanto a la dirección como al propietario del riesgo: la decisión deja de depender de una interpretación informal y pasa a ser auditable.
El Papel Del Propietario Del Riesgo Y La Dirección
El propietario del riesgo debe tener autoridad real sobre el proceso, activo o servicio afectado, o capacidad para elevar la decisión a quien sí la tenga. No basta con asignar el riesgo al responsable técnico si las consecuencias potenciales afectan a ingresos, cumplimiento contractual, privacidad o continuidad de negocio.
La cláusula 6.1.3 conecta el tratamiento con los controles, la Declaración de aplicabilidad y la aprobación. La explicación de ISO27001.com sobre la cláusula 6.1.3 recoge la necesidad de seleccionar el tratamiento, determinar controles y obtener la aprobación del propietario del riesgo.
La Declaración de aplicabilidad no debería ser un listado desconectado. Para cada riesgo relevante, deberíamos poder seguir la cadena completa:
- Escenario de riesgo y activo afectado.
- Decisión de tratamiento y controles seleccionados.
- Controles aplicables o no aplicables en la Declaración de aplicabilidad.
- Evidencia de implantación y eficacia.
- Valoración residual, decisión, propietario y fecha de revisión.
Esta trazabilidad permite explicar ante auditoría por qué un control está presente, por qué otro no aplica y qué exposición queda tras el tratamiento.
Cómo Documentar Una Aceptación Auditable
El registro de aceptación debe permitir que otra persona entienda la decisión sin reconstruir el contexto desde correos dispersos. Como mínimo, conviene incluir:
• Identificador del riesgo, activo, proceso y escenario evaluado.
• Valoración inherente, controles aplicados y valoración residual.
• Distinción entre riesgo residual previsto y verificado cuando el control aún esté madurando.
• Criterio de aceptación aplicable y razón por la que se cumple o se aprueba una excepción.
• Propietario del riesgo, decisor autorizado, fecha de decisión y periodo de vigencia.
• Evidencias revisadas, limitaciones conocidas, acciones pendientes y disparadores de reapertura.
La aceptación de un riesgo por encima del criterio ordinario debe ser excepcional, no automática. Debe contener una justificación de negocio, alternativas consideradas, controles compensatorios, una vigencia limitada y el nivel de aprobación correspondiente. Si el riesgo no puede aceptarse dentro de las reglas internas, debemos escalarlo o cambiar la actividad que lo genera.
Cuándo Reabrir Un Riesgo Ya Aceptado
Una aceptación no debería durar indefinidamente. Sorena AI señala que la aceptación forma parte del tratamiento y que las evaluaciones deben repetirse periódicamente o ante cambios relevantes.
Los disparadores operativos más útiles suelen ser los siguientes:
• Un incidente, una alerta significativa o un fallo de control.
• Un cambio de arquitectura, proveedor, ubicación de datos o proceso crítico.
• La aparición de una vulnerabilidad relevante en activos cubiertos por el riesgo.
• Una modificación legal, contractual o regulatoria aplicable.
• La expiración de una excepción o la falta de avance en el plan de tratamiento.
• Resultados de pruebas que contradigan la eficacia asumida del control.
Key Takeaways
• El riesgo residual ISO 27001 debe reflejar la exposición que queda después del tratamiento, no la expectativa optimista de que un control funcionará.
• Separar riesgo residual previsto y verificado ayuda a gestionar controles nuevos, parciales o pendientes de prueba.
• La reducción de probabilidad, la reducción de impacto y la transferencia son mecanismos distintos; no deben valorarse como si produjeran el mismo efecto.
• Una aceptación defendible vincula riesgo, activo, escenario, controles, Declaración de aplicabilidad, evidencia y decisor autorizado.
• Los riesgos por encima del umbral requieren tratamiento adicional, escalado o una excepción temporal formalmente aprobada.
• Incidentes, cambios relevantes y fallos de control deben reabrir la valoración residual aunque la fecha de revisión aún no haya llegado.
Preguntas Frecuentes
¿Qué Es Exactamente El Riesgo Residual En ISO 27001?
Es la exposición que permanece después de aplicar controles o medidas de tratamiento. No es necesariamente baja ni equivale a riesgo cero. Debemos compararla con los criterios de aceptación definidos por la organización y decidir si se acepta, se trata de nuevo, se evita o se escala.
¿Se Deben Volver A Valorar La Probabilidad Y El Impacto?
Sí. La valoración residual debe considerar cómo los controles cambian la probabilidad, el impacto o ambos. Si una copia de seguridad está implantada y probada, puede reducir el impacto de una pérdida de datos; no necesariamente evita el incidente que provoca esa pérdida.
¿Quién Debe Aceptar Formalmente El Riesgo Residual?
Debe aceptarlo el propietario del riesgo o una autoridad con capacidad suficiente para asumir sus consecuencias. Cuando el riesgo afecta a obligaciones legales, continuidad crítica o decisiones presupuestarias relevantes, la aprobación puede requerir escalado a dirección o a un comité de riesgos.
¿Qué Ocurre Si El Riesgo Residual Supera El Umbral De Aceptación?
La respuesta habitual es aplicar tratamiento adicional. Si no es viable de inmediato, puede ser necesaria una excepción documentada, temporal y aprobada por la autoridad adecuada. Mantener el riesgo sin tratamiento ni decisión explícita no constituye aceptación formal.
¿La Transferencia A Un Proveedor Elimina El Riesgo Residual?
No necesariamente. Un contrato, un acuerdo de nivel de servicio o un seguro pueden distribuir responsabilidades o costes, pero no eliminan automáticamente el impacto sobre la operación, la reputación, los datos o el cumplimiento. Debemos valorar qué consecuencias siguen siendo propias.
¿Cómo Se Demuestra Ante Un Auditor Que Un Control Funciona?
Con evidencia coherente con el objetivo del control: configuraciones, registros de ejecución, resultados de pruebas, cobertura de activos, revisiones de excepciones e indicadores de seguimiento. Una política o una captura aislada puede demostrar diseño o existencia, pero rara vez demuestra eficacia sostenida.
¿Cuándo Debe Revisarse Una Aceptación De Riesgo Residual?
En los intervalos definidos por el SGSI y cuando cambien las condiciones del riesgo. Un incidente, una modificación de proveedor, una vulnerabilidad crítica o un cambio de arquitectura son motivos suficientes para revisar antes de la fecha prevista.
Conclusión
Gestionar el riesgo residual ISO 27001 exige más que recalcular una matriz. Requiere distinguir entre controles planificados y controles eficaces, sostener la valoración con evidencia verificable y convertir la aceptación en una decisión consciente con responsable, vigencia y condiciones de revisión.
Cuando la trazabilidad entre riesgo, tratamiento, controles y evidencia es clara, el SGSI ofrece información útil para decidir y no solo documentación para auditoría. Los servicios de ISO 27001 pueden ayudar a revisar esa preparación desde la evidencia disponible, identificar brechas y priorizar acciones antes de una auditoría de certificación o seguimiento.
Sources/References
• ISO27001.com — ISO 2701:2022 Clause 6.1.3: Information Security Risk Treatment: https://iso27001.com/standard/clauses/6-1-3-risk-treatment/
• ForensicSpot — Risk Treatment and the Risk Register: https://forensicspot.com/topics/information-security-audit-and-compliance/risk-treatment-and-the-risk-register
• PJR — Determining the Scope of your Information Security Management System: http://www.pjr.com/downloads/webinar_slides/3.28.18%20Risk%20Assessment.pdf
• preeco — Residual Risk: Definition & Acceptance: https://www.preeco.de/en/glossary/information-security/residual-risk
• Sorena AI — ISO/IEC 27001 Risk Acceptance FAQ: https://www.sorena.io/artifacts/global/iso-2701/faq/risk-acceptance