ISO 27001 · el registro de riesgos
El registro de riesgos y el plan de tratamiento, redactados a partir de cinco respuestas
Los riesgos de partida que lleva una empresa de software, cada uno con una probabilidad y un impacto en una escala de 5 puntos, el nivel como su producto en 4 bandas, un umbral de aceptación, y para cada riesgo por encima una opción de tratamiento y los controles que lo tratan; el registro y el plan se redactan como los lee el auditor, y la declaración de aplicabilidad se deriva de los controles.
Dónde está el registro
14 riesgos en el registro, 14 por encima del umbral y tratados, 0 aceptados; 59 controles del anexo A nombrados por los tratamientos.
El registro (14 riesgos)
Los riesgos de partida son el primer borrador del producto para una empresa como la suya; cambie las puntuaciones, elija la opción, nombre al responsable, quite lo que no aplica y añada lo que falta.
El phishing lleva al compromiso de credenciales
Se engaña a un empleado para que revele credenciales. · Cuentas de usuario
A.6.3 Formar a las personas para trabajar con seguridad · A.8.5 Iniciar sesión con seguridad · A.8.23 Filtrar el acceso a sitios web arriesgados
16 · críticoPérdida o robo de un dispositivo endpoint
Se pierde o roban un portátil o teléfono que contiene información. · Endpoints
A.8.1 Asegurar portátiles, teléfonos y equipos de escritorio · A.7.9 Proteger los equipos que salen de las instalaciones · A.8.24 Usar bien el cifrado y gestionar las claves
9 · medioIndisponibilidad de un servicio en la nube crítico
Un proveedor SaaS o de nube clave sufre una interrupción. · Servicios en la nube
A.5.23 Usar los servicios en la nube con seguridad · A.8.14 Capacidad de reserva para sobrevivir a un fallo · A.5.30 Mantener la tecnología en marcha pese a la interrupción · A.5.29 Sostener la seguridad durante una crisis · A.8.6 Tener capacidad suficiente para seguir funcionando
12 · altoLas copias de seguridad no se restauran
Existen copias de seguridad, pero una restauración real no funciona cuando hace falta. · Datos
A.8.13 Hacer copias y demostrar que la restauración funciona
10 · altoUn empleado que se va conserva el acceso
El acceso no se revoca con rapidez cuando alguien se va. · Cuentas
A.5.11 Recuperar equipos y datos cuando alguien se va · A.6.5 Deberes que sobreviven a la salida o al cambio · A.5.18 Conceder, revisar y retirar permisos
9 · medioEquipos o soportes se desechan con datos todavía dentro
Un disco, una memoria USB o un portátil viejo sale de la empresa sin haber sido borrado. · Equipos y soportes
A.7.10 Manejar discos, unidades y soportes extraíbles · A.7.14 Borrar los equipos antes de desecharlos o reutilizarlos · A.8.10 Borrar los datos que ya no necesita
8 · medioBrecha en un proveedor o proveedor de nube
Un proveedor que guarda nuestra información o ejecuta parte de nuestro servicio se ve comprometido, y nos enteramos tarde o nunca. · Proveedores y servicios en la nube
A.5.19 Gestionar el riesgo que traen los proveedores · A.5.20 Llevar las cláusulas de seguridad a los contratos con proveedores · A.5.21 Seguridad a lo largo de la cadena de suministro tecnológica · A.5.22 Vigilar a los proveedores a medida que cambian
12 · altoIncidente no detectado ni notificado a tiempo
Nadie se percata de un evento de seguridad, o se percata alguien que no sabe dónde notificarlo, y la respuesta empieza con días de retraso. · Respuesta a incidentes
A.5.24 Estar listo antes de que ocurra un incidente · A.5.25 Juzgar qué eventos son incidentes reales · A.5.26 Actuar una vez declarado el incidente · A.5.27 Aprender de los incidentes después · A.6.8 Ponérselo fácil al personal para avisar de un problema
12 · altoRequisito legal o contractual omitido
Una ley, un reglamento, una licencia o un contrato con un cliente nos exige algo que nadie ha anotado, y la brecha la encuentra un auditor, un cliente o un regulador. · Registro de obligaciones
A.5.31 Conocer las leyes y los contratos que le obligan · A.5.32 Respetar los derechos de autor y las licencias de software · A.5.35 Hacer que alguien independiente revise la seguridad · A.5.36 Comprobar que sus propias reglas se cumplen · A.8.34 Auditar los sistemas sin perturbarlos
9 · medioResponsabilidades de seguridad poco claras o sin titular
Un control no tiene responsable designado, un deber es de todos y no lo hace nadie, o una persona reúne un rol que debería estar separado. · Roles y responsabilidades
A.5.1 Políticas de seguridad escritas, aprobadas y al día · A.5.2 Quién responde de qué en seguridad · A.5.3 Repartir las tareas delicadas entre varias personas · A.5.4 Lo que la dirección debe exigir a todos · A.5.37 Escribir cómo se hacen realmente las cosas · A.6.2 Deberes de seguridad en las condiciones de empleo
9 · medioPersonas que entran o salen sin lo básico de seguridad
Alguien empieza sin verificación, condiciones ni acuerdo de confidencialidad, o nadie sabe qué pasa cuando se incumple una norma. · Personas
A.6.1 Comprobaciones previas a la contratación · A.6.4 Consecuencias cuando se incumplen las reglas · A.6.6 Acuerdos de confidencialidad · A.5.5 Saber a quién acudir en las autoridades · A.5.6 Mantener el contacto con las comunidades de seguridad
9 · medioInformación compartida o transferida sin seguridad
Información confidencial se envía, transfiere o expone en una red o servicio sin el tratamiento que exige su clasificación. · Información en tránsito
A.5.13 Etiquetar la información con su sensibilidad · A.5.14 Enviar información con seguridad, dentro y fuera · A.8.3 Limitar lo que cada persona puede abrir · A.8.21 Acordar las condiciones de seguridad de los servicios de red · A.8.19 Controlar qué se instala en producción · A.5.8 Incorporar la seguridad a cada proyecto
12 · altoVulnerabilidad introducida en el software propio
Código o una dependencia inseguros llegan a producción. · Aplicación
A.8.25 Seguridad a lo largo de cómo se construye el software · A.8.26 Decidir qué debe hacer una aplicación con seguridad · A.8.27 Diseñar sistemas sobre principios seguros · A.8.28 Escribir código que resista los ataques · A.8.33 Usar datos seguros al probar · A.8.8 Encontrar y corregir las debilidades conocidas
12 · altoDivulgación no autorizada de datos personales
Datos personales de clientes quedan expuestos a la parte equivocada. · Datos personales
A.5.34 Proteger los datos personales · A.8.12 Impedir que los datos salgan por donde no deben · A.5.12 Clasificar la información por su sensibilidad · A.8.11 Ocultar los datos que no hace falta mostrar
15 · alto
Añadir un riesgo
El documento
# Evaluación de riesgos de seguridad de la información y plan de tratamiento Redactado el 14 de septiembre de 2026 con la página gratuita de getstandardos.com, para un sistema de gestión de seguridad de la información según ISO/IEC 27001:2022: los criterios del apartado 6.1.2 a), los riesgos identificados, analizados y evaluados según 6.1.2 c) a e), las opciones de tratamiento y los controles del anexo A según 6.1.3 a) a c), y el plan según 6.1.3 e). El método es el de StandardOS; los títulos de los controles son descripciones de StandardOS, no el texto de la norma. ## Criterios de riesgo La probabilidad y el impacto se puntúan cada uno de 1 a 5; el nivel es su producto. Un riesgo en 4 o por debajo se acepta y se conserva con un responsable; un riesgo por encima se trata. Las bandas: - bajo: 1 a 4 - medio: 5 a 9 - alto: 10 a 15 - crítico: 16 a 25 ## Registro de riesgos (14 riesgos) | Riesgo | Activo | Probabilidad | Impacto | Nivel | Tratamiento | Responsable | |---|---|---|---|---|---|---| | El phishing lleva al compromiso de credenciales | Cuentas de usuario | 4 | 4 | 16 (crítico) | Modificar con controles | | | Pérdida o robo de un dispositivo endpoint | Endpoints | 3 | 3 | 9 (medio) | Modificar con controles | | | Indisponibilidad de un servicio en la nube crítico | Servicios en la nube | 3 | 4 | 12 (alto) | Modificar con controles | | | Las copias de seguridad no se restauran | Datos | 2 | 5 | 10 (alto) | Modificar con controles | | | Un empleado que se va conserva el acceso | Cuentas | 3 | 3 | 9 (medio) | Modificar con controles | | | Equipos o soportes se desechan con datos todavía dentro | Equipos y soportes | 2 | 4 | 8 (medio) | Modificar con controles | | | Brecha en un proveedor o proveedor de nube | Proveedores y servicios en la nube | 3 | 4 | 12 (alto) | Modificar con controles | | | Incidente no detectado ni notificado a tiempo | Respuesta a incidentes | 3 | 4 | 12 (alto) | Modificar con controles | | | Requisito legal o contractual omitido | Registro de obligaciones | 3 | 3 | 9 (medio) | Modificar con controles | | | Responsabilidades de seguridad poco claras o sin titular | Roles y responsabilidades | 3 | 3 | 9 (medio) | Modificar con controles | | | Personas que entran o salen sin lo básico de seguridad | Personas | 3 | 3 | 9 (medio) | Modificar con controles | | | Información compartida o transferida sin seguridad | Información en tránsito | 3 | 4 | 12 (alto) | Modificar con controles | | | Vulnerabilidad introducida en el software propio | Aplicación | 3 | 4 | 12 (alto) | Modificar con controles | | | Divulgación no autorizada de datos personales | Datos personales | 3 | 5 | 15 (alto) | Modificar con controles | | ## Plan de tratamiento de riesgos (14 riesgos tratados) Cada riesgo por encima del nivel de aceptación de 4, con su opción de tratamiento, los controles que lo tratan cuando la opción es modificar, y su responsable; 0 riesgos se aceptan y conservan. ### El phishing lleva al compromiso de credenciales Se engaña a un empleado para que revele credenciales. Nivel: 16 (crítico). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.6.3: Formar a las personas para trabajar con seguridad - A.8.5: Iniciar sesión con seguridad - A.8.23: Filtrar el acceso a sitios web arriesgados ### Pérdida o robo de un dispositivo endpoint Se pierde o roban un portátil o teléfono que contiene información. Nivel: 9 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.8.1: Asegurar portátiles, teléfonos y equipos de escritorio - A.7.9: Proteger los equipos que salen de las instalaciones - A.8.24: Usar bien el cifrado y gestionar las claves ### Indisponibilidad de un servicio en la nube crítico Un proveedor SaaS o de nube clave sufre una interrupción. Nivel: 12 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.23: Usar los servicios en la nube con seguridad - A.8.14: Capacidad de reserva para sobrevivir a un fallo - A.5.30: Mantener la tecnología en marcha pese a la interrupción - A.5.29: Sostener la seguridad durante una crisis - A.8.6: Tener capacidad suficiente para seguir funcionando ### Las copias de seguridad no se restauran Existen copias de seguridad, pero una restauración real no funciona cuando hace falta. Nivel: 10 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.8.13: Hacer copias y demostrar que la restauración funciona ### Un empleado que se va conserva el acceso El acceso no se revoca con rapidez cuando alguien se va. Nivel: 9 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.11: Recuperar equipos y datos cuando alguien se va - A.6.5: Deberes que sobreviven a la salida o al cambio - A.5.18: Conceder, revisar y retirar permisos ### Equipos o soportes se desechan con datos todavía dentro Un disco, una memoria USB o un portátil viejo sale de la empresa sin haber sido borrado. Nivel: 8 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.7.10: Manejar discos, unidades y soportes extraíbles - A.7.14: Borrar los equipos antes de desecharlos o reutilizarlos - A.8.10: Borrar los datos que ya no necesita ### Brecha en un proveedor o proveedor de nube Un proveedor que guarda nuestra información o ejecuta parte de nuestro servicio se ve comprometido, y nos enteramos tarde o nunca. Nivel: 12 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.19: Gestionar el riesgo que traen los proveedores - A.5.20: Llevar las cláusulas de seguridad a los contratos con proveedores - A.5.21: Seguridad a lo largo de la cadena de suministro tecnológica - A.5.22: Vigilar a los proveedores a medida que cambian ### Incidente no detectado ni notificado a tiempo Nadie se percata de un evento de seguridad, o se percata alguien que no sabe dónde notificarlo, y la respuesta empieza con días de retraso. Nivel: 12 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.24: Estar listo antes de que ocurra un incidente - A.5.25: Juzgar qué eventos son incidentes reales - A.5.26: Actuar una vez declarado el incidente - A.5.27: Aprender de los incidentes después - A.6.8: Ponérselo fácil al personal para avisar de un problema ### Requisito legal o contractual omitido Una ley, un reglamento, una licencia o un contrato con un cliente nos exige algo que nadie ha anotado, y la brecha la encuentra un auditor, un cliente o un regulador. Nivel: 9 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.31: Conocer las leyes y los contratos que le obligan - A.5.32: Respetar los derechos de autor y las licencias de software - A.5.35: Hacer que alguien independiente revise la seguridad - A.5.36: Comprobar que sus propias reglas se cumplen - A.8.34: Auditar los sistemas sin perturbarlos ### Responsabilidades de seguridad poco claras o sin titular Un control no tiene responsable designado, un deber es de todos y no lo hace nadie, o una persona reúne un rol que debería estar separado. Nivel: 9 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.1: Políticas de seguridad escritas, aprobadas y al día - A.5.2: Quién responde de qué en seguridad - A.5.3: Repartir las tareas delicadas entre varias personas - A.5.4: Lo que la dirección debe exigir a todos - A.5.37: Escribir cómo se hacen realmente las cosas - A.6.2: Deberes de seguridad en las condiciones de empleo ### Personas que entran o salen sin lo básico de seguridad Alguien empieza sin verificación, condiciones ni acuerdo de confidencialidad, o nadie sabe qué pasa cuando se incumple una norma. Nivel: 9 (medio). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.6.1: Comprobaciones previas a la contratación - A.6.4: Consecuencias cuando se incumplen las reglas - A.6.6: Acuerdos de confidencialidad - A.5.5: Saber a quién acudir en las autoridades - A.5.6: Mantener el contacto con las comunidades de seguridad ### Información compartida o transferida sin seguridad Información confidencial se envía, transfiere o expone en una red o servicio sin el tratamiento que exige su clasificación. Nivel: 12 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.13: Etiquetar la información con su sensibilidad - A.5.14: Enviar información con seguridad, dentro y fuera - A.8.3: Limitar lo que cada persona puede abrir - A.8.21: Acordar las condiciones de seguridad de los servicios de red - A.8.19: Controlar qué se instala en producción - A.5.8: Incorporar la seguridad a cada proyecto ### Vulnerabilidad introducida en el software propio Código o una dependencia inseguros llegan a producción. Nivel: 12 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.8.25: Seguridad a lo largo de cómo se construye el software - A.8.26: Decidir qué debe hacer una aplicación con seguridad - A.8.27: Diseñar sistemas sobre principios seguros - A.8.28: Escribir código que resista los ataques - A.8.33: Usar datos seguros al probar - A.8.8: Encontrar y corregir las debilidades conocidas ### Divulgación no autorizada de datos personales Datos personales de clientes quedan expuestos a la parte equivocada. Nivel: 15 (alto). Tratamiento: Modificar con controles. Responsable: aún sin nombrar Controles que tratan este riesgo: - A.5.34: Proteger los datos personales - A.8.12: Impedir que los datos salgan por donde no deben - A.5.12: Clasificar la información por su sensibilidad - A.8.11: Ocultar los datos que no hace falta mostrar ## Controles nombrados por el plan (59) Los controles del anexo A que nombra el plan de tratamiento, y que la declaración de aplicabilidad lleva después como aplicables: - A.5.1: Políticas de seguridad escritas, aprobadas y al día - A.5.2: Quién responde de qué en seguridad - A.5.3: Repartir las tareas delicadas entre varias personas - A.5.4: Lo que la dirección debe exigir a todos - A.5.5: Saber a quién acudir en las autoridades - A.5.6: Mantener el contacto con las comunidades de seguridad - A.5.8: Incorporar la seguridad a cada proyecto - A.5.11: Recuperar equipos y datos cuando alguien se va - A.5.12: Clasificar la información por su sensibilidad - A.5.13: Etiquetar la información con su sensibilidad - A.5.14: Enviar información con seguridad, dentro y fuera - A.5.18: Conceder, revisar y retirar permisos - A.5.19: Gestionar el riesgo que traen los proveedores - A.5.20: Llevar las cláusulas de seguridad a los contratos con proveedores - A.5.21: Seguridad a lo largo de la cadena de suministro tecnológica - A.5.22: Vigilar a los proveedores a medida que cambian - A.5.23: Usar los servicios en la nube con seguridad - A.5.24: Estar listo antes de que ocurra un incidente - A.5.25: Juzgar qué eventos son incidentes reales - A.5.26: Actuar una vez declarado el incidente - A.5.27: Aprender de los incidentes después - A.5.29: Sostener la seguridad durante una crisis - A.5.30: Mantener la tecnología en marcha pese a la interrupción - A.5.31: Conocer las leyes y los contratos que le obligan - A.5.32: Respetar los derechos de autor y las licencias de software - A.5.34: Proteger los datos personales - A.5.35: Hacer que alguien independiente revise la seguridad - A.5.36: Comprobar que sus propias reglas se cumplen - A.5.37: Escribir cómo se hacen realmente las cosas - A.6.1: Comprobaciones previas a la contratación - A.6.2: Deberes de seguridad en las condiciones de empleo - A.6.3: Formar a las personas para trabajar con seguridad - A.6.4: Consecuencias cuando se incumplen las reglas - A.6.5: Deberes que sobreviven a la salida o al cambio - A.6.6: Acuerdos de confidencialidad - A.6.8: Ponérselo fácil al personal para avisar de un problema - A.7.9: Proteger los equipos que salen de las instalaciones - A.7.10: Manejar discos, unidades y soportes extraíbles - A.7.14: Borrar los equipos antes de desecharlos o reutilizarlos - A.8.1: Asegurar portátiles, teléfonos y equipos de escritorio - A.8.3: Limitar lo que cada persona puede abrir - A.8.5: Iniciar sesión con seguridad - A.8.6: Tener capacidad suficiente para seguir funcionando - A.8.8: Encontrar y corregir las debilidades conocidas - A.8.10: Borrar los datos que ya no necesita - A.8.11: Ocultar los datos que no hace falta mostrar - A.8.12: Impedir que los datos salgan por donde no deben - A.8.13: Hacer copias y demostrar que la restauración funciona - A.8.14: Capacidad de reserva para sobrevivir a un fallo - A.8.19: Controlar qué se instala en producción - A.8.21: Acordar las condiciones de seguridad de los servicios de red - A.8.23: Filtrar el acceso a sitios web arriesgados - A.8.24: Usar bien el cifrado y gestionar las claves - A.8.25: Seguridad a lo largo de cómo se construye el software - A.8.26: Decidir qué debe hacer una aplicación con seguridad - A.8.27: Diseñar sistemas sobre principios seguros - A.8.28: Escribir código que resista los ataques - A.8.33: Usar datos seguros al probar - A.8.34: Auditar los sistemas sin perturbarlos Los riesgos son un primer borrador para una empresa de este perfil y las puntuaciones son las de la empresa; los controles se leen de los datos del anexo A del paquete. Esto es un documento, no un certificado.
El registro con el que empieza la declaración
StandardOS siembra los mismos riesgos de partida el primer día, mantiene la puntuación, el responsable y la fecha de revisión en cada uno, convierte cada tratamiento en una posición de la declaración de aplicabilidad, y reabre la evaluación en el intervalo que pide el apartado 8.2.
La escala, las bandas y el umbral son el método propio de StandardOS; la norma pide criterios y deja el método a la organización. Los riesgos de partida se leen del paquete, nunca se teclean en esta página, y sus referencias de controles son identificadores del anexo A con los títulos propios de StandardOS. Esto es un documento, no asesoramiento jurídico ni de certificación.