Registro de riesgos ISO 27001: estructura y ejemplos de entradas
Un registro de riesgos ISO 27001 es la información documentada que resulta del proceso de apreciación de riesgos exigido por el Apartado 6.1.2: riesgos para la confidencialidad, la integridad y la disponibilidad de la información dentro del alcance de tu SGSI, cada uno con un propietario del riesgo con nombre y apellidos, una consecuencia y una probabilidad analizadas, y una evaluación frente a tus propios criterios de riesgo. Las columnas que importan son las que la norma implica: descripción del riesgo ligada a un activo y a una amenaza, propietario, consecuencia, probabilidad, nivel de riesgo resultante, opción de tratamiento, controles seleccionados y el riesgo residual que el propietario aceptó. Diez entradas concretas que revisas de verdad valen más que cien filas genéricas que te descargaste.
Un registro de riesgos ISO 27001 es la información documentada que resulta del proceso de apreciación de riesgos exigido por el Apartado 6.1.2. Recoge los riesgos para la confidencialidad, la integridad y la disponibilidad de la información dentro del alcance de tu SGSI, cada uno con un propietario con nombre y apellidos, una consecuencia y una probabilidad analizadas, y una evaluación frente a los criterios de riesgo que definiste de antemano.
Si primero quieres la versión general del concepto, sin ISO de por medio, tenemos una introducción a qué es un registro de riesgos y por qué cualquier empresa en crecimiento se beneficia de tener uno. Este artículo es más específico: la estructura que sobrevive a una auditoría de certificación y cinco entradas trabajadas que puedes adaptar.
Qué exige realmente el Apartado 6.1.2
La norma no impone un formato, pero sí impone un proceso, y el proceso implica las columnas. El Apartado 6.1.2 te exige definir y aplicar un proceso de apreciación de riesgos que:
- Establezca y mantenga criterios de riesgo, incluidos los criterios de aceptación del riesgo y los criterios para realizar apreciaciones. Decide qué significa «alto» y con qué estás dispuesto a convivir antes de empezar a puntuar, no después.
- Produzca resultados coherentes, válidos y comparables cuando se repita. Dos personas que aprecien el mismo riesgo deberían llegar más o menos al mismo sitio, y la apreciación de este año debería ser comparable con la del año pasado.
- Identifique los riesgos asociados a la pérdida de confidencialidad, integridad y disponibilidad de la información dentro del alcance.
- Identifique a los propietarios del riesgo: personas con nombre, no departamentos.
- Analice los riesgos: valore las consecuencias realistas y la probabilidad, y determine el nivel de riesgo resultante.
- Evalúe los riesgos: compáralos con tus criterios y priorízalos para su tratamiento.
El Apartado 6.1.2 también te exige conservar información documentada sobre el proceso. El registro es la forma en que la mayoría de las organizaciones lo cumplen.
El conjunto mínimo de columnas
Cada columna de abajo se corresponde con algo que pide la norma. Si una columna de tu plantilla no lo hace, es decoración, y la decoración es lo que convierte un registro en una tarea que nadie actualiza.
| Columna | Por qué existe |
|---|---|
| ID | Una referencia estable para que los planes de tratamiento y los hallazgos de auditoría puedan apuntar a ella |
| Descripción del riesgo | Activo + amenaza + consecuencia, en una frase concreta |
| Activo o proceso afectado | Vincula el riesgo con tu inventario de activos |
| Impacto CID | Cuál de las tres —confidencialidad, integridad, disponibilidad— está en juego |
| Propietario del riesgo | Apartado 6.1.2 c) 2: una persona concreta que pueda decidir de verdad |
| Consecuencia | Impacto analizado, puntuado según tus criterios |
| Probabilidad | Probabilidad realista, puntuada según tus criterios |
| Nivel de riesgo | El nivel resultante, evaluado frente a los criterios de aceptación |
| Opción de tratamiento | Modificar, retener, evitar o compartir |
| Controles seleccionados | Los controles que lo tratan, con referencia cruzada a tu SoA |
| Riesgo residual | El nivel tras el tratamiento, y si el propietario lo aceptó |
| Fecha de revisión | Cuándo se miró por última vez, para que se vea si está obsoleto |
Cinco entradas trabajadas
Están escritas para una startup cloud-native. La puntuación usa una escala sencilla de 1 a 5 para consecuencia y probabilidad, con el nivel de riesgo como producto de ambas, algo más que suficiente para un equipo pequeño: a la norma le importa que tu método sea coherente, no que sea sofisticado.
R-01 — Un empleado que se marcha conserva acceso a un SaaS
Descripción: Un empleado se va y no se revoca su acceso a una herramienta SaaS fuera del SSO, lo que le permite seguir accediendo a datos de clientes. Activo: plataforma de soporte al cliente. CID: confidencialidad. Propietario: responsable de Operaciones. Consecuencia 4, Probabilidad 3, Nivel 12. Tratamiento: modificar — checklist de offboarding que cubra las herramientas fuera de SSO, más revisiones de accesos de usuario trimestrales. Residual: 4, aceptado.
R-02 — Una caída de la región cloud supera el objetivo de recuperación
Descripción: Un fallo prolongado de una zona de disponibilidad del proveedor de hosting deja la plataforma fuera de servicio más allá del objetivo de tiempo de recuperación comprometido en los contratos con clientes. Activo: plataforma de producción. CID: disponibilidad. Propietario: CTO. Consecuencia 4, Probabilidad 2, Nivel 8. Tratamiento: modificar — despliegue multi-AZ, runbook de recuperación documentado y probado anualmente. Residual: 4, aceptado.
R-03 — Un fenómeno meteorológico extremo interrumpe a un proveedor crítico
Descripción: Inundaciones o tensión en la red eléctrica por calor extremo en las instalaciones de un proveedor interrumpen un servicio del que depende la plataforma. Activo: servicio prestado por el proveedor. CID: disponibilidad. Propietario: CTO. Consecuencia 3, Probabilidad 2, Nivel 6. Tratamiento: retener, con seguimiento — compromisos de continuidad del proveedor revisados anualmente. Merece la pena incluirlo de forma explícita, ya que la modificación de 2024 introdujo las consideraciones climáticas en los Apartados 4.1 y 4.2 — mira la modificación de la que nadie te habló. Residual: 6, aceptado.
R-04 — Secretos subidos al control de versiones
Descripción: Se suben claves de API o credenciales a un repositorio y quedan expuestas a cualquiera con acceso al repo, o públicamente si el repo llega a abrirse. Activo: repositorios de código fuente. CID: confidencialidad. Propietario: responsable de Ingeniería. Consecuencia 5, Probabilidad 3, Nivel 15. Tratamiento: modificar — escaneo automático de secretos en CI, gestor de secretos y procedimiento de rotación. Consulta los controles de desarrollo seguro. Residual: 5, aceptado.
R-05 — Dependencia de una sola persona para desplegar en producción
Descripción: Solo una persona del equipo de ingeniería tiene el conocimiento y los accesos necesarios para desplegar y recuperar producción, lo que crea un riesgo de disponibilidad si no está localizable. Activo: pipeline de despliegue. CID: disponibilidad. Propietario: CTO. Consecuencia 4, Probabilidad 3, Nivel 12. Tratamiento: modificar — runbooks documentados, una segunda persona formada y procedimiento de acceso de emergencia. Residual: 6, aceptado.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Los propietarios del riesgo son personas, no departamentos
«TI» no puede aceptar un riesgo. «Ingeniería» no puede aprobar un plan de tratamiento. El Apartado 6.1.2 te pide identificar propietarios del riesgo porque después el Apartado 6.1.3 exige que esos propietarios aprueben el plan de tratamiento de riesgos y acepten los riesgos residuales, y eso solo lo puede hacer una persona.
En una empresa pequeña se repetirán los mismos dos o tres nombres, y no pasa nada. Lo que importa es que el propietario designado tenga autoridad para financiar una solución o para aceptar vivir sin ella. Si tu registro lista un propietario que no puede hacer ni una cosa ni la otra, la entrada es decorativa.
Cómo alimenta el registro a la SoA
El registro no es el final de la cadena. Según el Apartado 6.1.3, coges los riesgos evaluados y:
- Seleccionas opciones de tratamiento: modificar, retener, evitar o compartir.
- Determinas los controles necesarios para implementar esas opciones.
- Comparas los controles que has determinado con el Anexo A para verificar que no se te ha pasado ningún control necesario. El Anexo A es una comprobación cruzada, no una lista de la compra.
- Elaboras una Declaración de Aplicabilidad que recoja qué controles aplican, por qué y si están implementados.
- Formulas un plan de tratamiento de riesgos y obtienes la aprobación del plan por parte de los propietarios del riesgo, además de su aceptación de los riesgos residuales.
Un auditor recorrerá esta cadena en ambas direcciones. Elegirá un control marcado como «aplicable» en tu SoA y preguntará qué riesgo lo motivó. Después elegirá un riesgo con puntuación alta en tu registro y preguntará qué controles lo tratan. Un registro que no cuadra con la SoA es uno de los hallazgos más incómodos de recibir, porque sugiere que los dos documentos se elaboraron por separado, que suele ser exactamente lo que pasó.
Los antipatrones
- La descarga de cien filas. Una plantilla genérica poblada con riesgos que no tienen nada que ver con tu negocio. Parece exhaustiva y se revisa fatal, porque nadie reconoce nada de lo que hay ahí.
- Riesgos escritos como categorías. «Riesgo cibernético» no es un riesgo. «Exfiltración de datos de clientes a través de una cuenta de administrador comprometida» sí lo es.
- Teatro de la puntuación. Fórmulas elaboradas sin criterios documentados. La norma quiere coherencia y comparabilidad, y eso lo consigue mejor una escala sencilla y escrita que un algoritmo sin explicar.
- Sin riesgo residual. Si nunca registras qué queda después del tratamiento, el propietario no tiene nada que aceptar, y el Apartado 6.1.3 le pide que lo acepte.
- El registro congelado. Las mismas doce filas, las mismas puntuaciones, las mismas fechas, año tras año. Es el hallazgo más habitual en las auditorías de seguimiento, porque se ve a la legua.
La conclusión
Construye el registro en torno a lo que pide el Apartado 6.1.2: riesgos concretos ligados a activos reales, propietarios designados con autoridad, criterios que escribiste antes de puntuar y riesgo residual que alguien aceptó de verdad. Después revísalo con una cadencia y deja que la revisión se note en las fechas. Diez entradas que mantienes de verdad pasarán una auditoría que cien filas heredadas no pasarán.
Siguiente: el Apartado 6 al completo, metodologías de apreciación de riesgos si aún estás eligiendo un enfoque, o mira cómo la evaluación de riesgos en AuditBadger mantiene el registro, el plan de tratamiento y la SoA apuntando en la misma dirección.
