Registro de Riesgos ISO 27001 Listo para Auditoría para Equipos SGSI, Una Plantilla Descargable

Un registro de riesgos ISO 27001 es el documento de trabajo que recoge cada escenario de riesgo identificado, su probabilidad e impacto, el responsable, la decisión de tratamiento y el riesgo residual que queda tras aplicar los controles, vinculado directamente a la Cláusula 6.1.3 y a la Declaración de Aplicabilidad. Si aún no has comenzado, el camino más rápido es abrir una plantilla con esos campos ya incorporados y empezar a rellenar tu inventario de activos hoy mismo.

Resumen rápido:

• Un registro de riesgos es esencial para demostrar el cumplimiento en auditoría, vinculando cada escenario de riesgo, decisión de control y justificación en un formato trazable y estructurado.
• Construir un inventario de activos limpio con clasificaciones claras y asignación de responsabilidad es un requisito previo para obtener escenarios de riesgo creíbles y una puntuación coherente.
• Los escenarios de riesgo eficaces identifican activos, amenazas, vulnerabilidades e impactos concretos utilizando datos reales procedentes de registros, CVEs e historial de incidentes, evitando las conjeturas.
• Un esquema de registro bien diseñado debe incluir identificadores únicos de riesgo, acciones de tratamiento con responsables y plazos, riesgo residual y vínculos a evidencias técnicas.
• La revisión periódica, la asignación de responsabilidad y el mantenimiento del historial de versiones son fundamentales para mantener el registro preciso, útil y listo para auditoría a lo largo del tiempo.

Tabla de contenidos

• Por qué el registro de riesgos importa para la preparación de la auditoría
• Construir un inventario de activos antes de poder evaluar cualquier cosa
• Redactar escenarios de riesgo que resistan el escrutinio
• Elegir el esquema del registro: columnas, herramientas y control de versiones
• Puntuar, priorizar y mapear el tratamiento con la Declaración de Aplicabilidad
• Un ejemplo desarrollado y una plantilla con la que puedes empezar hoy
• Mantener el registro activo: cadencia, responsabilidad e informes
• Alinear tu registro con el modelo de reporte de riesgos empresariales de NIST
• Lo que los auditores señalan realmente cuando examinan un registro
• ISMS Calculator: validar las estimaciones de esfuerzo y plazos de tu registro
• Fuentes primarias y plantillas
• Fuentes
• Preguntas frecuentes

Por qué el registro de riesgos importa para la preparación de la auditoría

Los auditores no dan por buena tu palabra de que la evaluación de riesgos se realizó. Te piden verla, fila por fila, y trazan una línea desde un riesgo identificado hasta una decisión de control y una justificación documentada en la Declaración de Aplicabilidad. El registro es esa cadena de evidencias. Sin él, la Cláusula 6.1.3 de ISO/IEC 27001:2022 no tiene nada a lo que remitirse, y la Declaración de Aplicabilidad se convierte en una lista de afirmaciones en lugar de un conjunto de decisiones defendibles.

El registro también realiza un trabajo real más allá de la apariencia de cumplimiento. Es el mecanismo que convierte una evaluación de riesgos en selección de controles. Cuando un escenario de riesgo supera el umbral de apetito definido, el registro debe mostrar qué control se eligió, por qué y qué riesgo queda después. Esa cadena de razonamiento es exactamente lo que espera la guía de ISO/IEC 27001 cuando establece que los controles necesarios deben identificarse antes de consultar el Anexo A para encontrar una correspondencia.

Un error frecuente es incluir cada detalle técnico en el propio registro: extractos de registros sin procesar, resultados de análisis de vulnerabilidades, historiales de tickets. Esto produce un documento que nadie puede leer en una revisión de gestión. El patrón más eficaz, tomado de la práctica de riesgos empresariales, separa el registro en filas de resumen concisas y un registro de detalle vinculado para cada una de ellas:

• La fila del registro expone el escenario, la puntuación, el responsable y la decisión en un lenguaje que un directivo puede revisar en segundos.
• Un Registro de Detalle de Riesgo (RDR) vinculado contiene la evidencia: resultados de análisis, marcas de tiempo de registros, tickets de remediación y resultados de pruebas.
• Los auditores examinan el registro y luego consultan el RDR vinculado para cualquier fila que quieran verificar.
• Las revisiones de gestión se mantienen breves porque nadie tiene que desplazarse por detalles técnicos para encontrar la decisión.

Esta separación mantiene el registro útil para sus dos audiencias a la vez: las personas que necesitan actuar sobre un riesgo y las que necesitan demostrar que se gestionó.

Construir un inventario de activos antes de poder evaluar cualquier cosa

No es posible redactar un escenario de riesgo creíble sin saber qué activo está expuesto. Aquí es donde la mayoría de los equipos que construyen un SGSI por primera vez se estancan: intentan escribir filas de riesgo antes de disponer de un inventario de activos limpio, y el registro acaba lleno de entradas vagas como "la red" o "datos de clientes" sin responsable ni límite definido.

Comienza definiendo la clasificación y la criticidad antes de enumerar un solo activo. Decide, por escrito, qué hace que un activo sea de criticidad "alta", "media" o "baja" para tu organización. Los criterios habituales incluyen si el activo contiene datos personales regulados, si su pérdida detendría un proceso generador de ingresos y cuánto tiempo podría tolerar el negocio su indisponibilidad. Fijar estas definiciones primero significa que cada activo se puntúa de la misma manera, independientemente de quién lo registre.

Una vez que existen los criterios, sigue una secuencia repetible:

1. Extrae primero los inventarios existentes: exportaciones de CMDB, listas de recursos de cuentas en la nube y etiquetas de activos de herramientas de gestión de endpoints te ofrecen una línea base rápida.
2. Entrevista a los propietarios de procesos en finanzas, RRHH y operaciones para detectar TI en la sombra y procesos manuales que nunca aparecen en una CMDB.
3. Asigna a cada activo un responsable que sea accountable de las decisiones de riesgo asociadas, no solo un custodio que lo administre.
4. Etiqueta el nivel de confidencialidad, la ubicación física o lógica y el proceso de negocio al que da soporte cada activo.
5. Reconcilia los duplicados y retira las entradas de sistemas dados de baja antes de que contaminen tus escenarios de riesgo.

Las categorías prácticas de activos suelen abarcar activos de información (bases de datos, repositorios documentales), software, hardware e infraestructura, personas y roles con acceso privilegiado, ubicaciones físicas y servicios de terceros. Para cada uno, captura los metadatos suficientes para redactar un escenario de riesgo más adelante: responsable, ubicación, clasificación de confidencialidad y el proceso de negocio al que se vincula. Omitir cualquiera de estos campos es la principal razón por la que las filas de riesgo resultan demasiado vagas para puntuarse de forma coherente.

Consejo profesional: Realiza el descubrimiento de activos y el taller de riesgos en la misma semana. Los activos descubiertos de forma aislada tienden a quedar sin usar durante meses porque nadie los conecta a una conversación de riesgo en curso.

Los problemas de calidad de datos son predecibles. Los equipos cuentan dos veces el mismo activo bajo dos nombres distintos, olvidan asignar un responsable y dejan el campo en blanco, o importan un volcado de CMDB sin filtrar los entornos de prueba y staging que no tienen impacto real en el negocio. Corrígelos antes de empezar a puntuar, porque cada fila de riesgo posterior hereda la calidad de los datos del activo.

Redactar escenarios de riesgo que resistan el escrutinio

Una fila de registro de riesgos solo es útil en la medida en que lo sea la frase que describe el riesgo. "Riesgo de ransomware" no le dice nada a un auditor. Un escenario estructurado hace el trabajo: nombra el activo, el agente de amenaza, la vulnerabilidad que explota y el impacto empresarial concreto, expresado en términos de confidencialidad, integridad o disponibilidad.

Una plantilla funcional tiene este aspecto: [activo] está expuesto a [agente de amenaza] que explota [vulnerabilidad], lo que resulta en [pérdida de confidencialidad/integridad/disponibilidad] y [consecuencia para el negocio]. Por ejemplo: la base de datos de facturación de clientes está expuesta a un atacante externo que explota un servidor de base de datos sin parches, lo que resulta en la pérdida de confidencialidad de los registros de pago y en obligaciones de notificación regulatoria. Esa frase te proporciona todo lo necesario para asignar probabilidad, impacto y, finalmente, un responsable de tratamiento.

Los escenarios creíbles necesitan fuentes creíbles, no conjeturas sacadas de la pizarra de un taller. Obtén datos de amenazas y vulnerabilidades de:

• Registros internos y alertas del SIEM que muestren lo que realmente se ha intentado contra tu entorno.
• Avisos de seguridad de proveedores y suministradores, en especial para software de terceros con cronologías de CVE conocidas.
• Bases de datos de CVE publicadas mapeadas contra tu propio inventario de activos para identificar exposiciones sin parches.
• Historial de incidentes de tu propia organización o sector, cuando esté disponible, en lugar de afirmaciones genéricas del sector.

Nuestra guía de metodología de evaluación de riesgos desarrolla este proceso de construcción de escenarios con mayor profundidad si deseas una secuencia más detallada.

Asignar probabilidad e impacto es donde la criticidad del activo justifica su existencia. Una vulnerabilidad en un servidor de pruebas de baja criticidad y la vulnerabilidad idéntica en una pasarela de pago en producción nunca deberían tener la misma puntuación de riesgo, aunque el fallo técnico sea el mismo. El impacto debe puntuarse en función de la clasificación de criticidad del activo que ya definiste, no en función de una escala de severidad genérica tomada de un escáner de vulnerabilidades. La probabilidad debe reflejar lo que sabes sobre la exposición: si el activo está orientado a internet, si se encuentra detrás de segmentación de red, si esta clase exacta de vulnerabilidad ya te ha afectado antes. Las valoraciones de probabilidad vagas ("media, probablemente") son la debilidad más común que los auditores señalan cuando examinan un registro.

Elegir el esquema del registro: columnas, herramientas y control de versiones

Las columnas que elijas determinan si el registro será utilizable dentro de seis meses o si colapsará convirtiéndose en una hoja de cálculo imposible de mantener. Un esquema recomendado, construido en torno a lo que los auditores realmente esperan ver, incluye:

• ID de riesgo: un identificador único y estable que nunca se reutiliza, para que las referencias históricas y los vínculos al RDR permanezcan válidos.
• Descripción del riesgo: la frase del escenario estructurado, no una etiqueta de una sola palabra.
• Referencia al activo: un vínculo de vuelta a la entrada del inventario de activos, evitando datos de activo duplicados.
• Impacto en CIA: cuál de los tres pilares —confidencialidad, integridad o disponibilidad— se ve afectado y de qué manera.
• Valoraciones de probabilidad e impacto: puntuadas según los criterios definidos, no según una apreciación subjetiva variable.
• Puntuación de riesgo: el resultado calculado de probabilidad por impacto, o tu ponderación elegida.
• Controles existentes y eficacia del control: qué está ya implantado y qué tan bien funciona.
• Acción de tratamiento, responsable y fecha objetivo: la decisión, quién es accountable y cuándo debe completarse.
• Riesgo residual: la puntuación que queda tras el tratamiento, que es lo que la dirección realmente necesita ver.
• Vínculo al Registro de Detalle de Riesgo: dónde reside la evidencia técnica.
• Fecha de última revisión: prueba de que la fila se mantiene actualizada, no que se creó una vez y se olvidó.

Una hoja de cálculo es genuinamente suficiente para organizaciones más pequeñas con un número modesto de activos y un único responsable del SGSI que mantenga el archivo al día. Es rápida de construir, fácil de muestrear para los auditores y económica de mantener. Deja de ser suficiente cuando múltiples unidades de negocio contribuyen con riesgos, se necesita automatización de flujos de trabajo para los plazos de tratamiento, o se requiere control de acceso basado en roles para que no todo el mundo pueda editar cualquier fila. En ese punto, una plataforma GRC justifica su coste, principalmente a través de recordatorios automatizados, pistas de auditoría y la posibilidad de agregar riesgos entre departamentos sin consolidación manual.

Consejo profesional: Si migras de una hoja de cálculo a una herramienta GRC más adelante, mantén el formato de los IDs de riesgo estable desde el primer día. Renumerar las filas durante la migración rompe todas las referencias históricas de auditoría y los vínculos al RDR que hayas construido.

Sea cual sea el formato que elijas, el control de versiones no es opcional. Restringe quién puede editar el registro maestro, registra cada cambio con una marca de tiempo y el nombre del editor, y mantén las versiones anteriores recuperables en lugar de sobreescritas. Los auditores preguntan con frecuencia cómo ha cambiado la puntuación de un riesgo concreto a lo largo del tiempo, y una hoja de cálculo sin historial de cambios no puede responder a esa pregunta.

Puntuar, priorizar y mapear el tratamiento con la Declaración de Aplicabilidad

Tres enfoques de puntuación cubren la mayoría de las organizaciones. Un modelo cualitativo simple de tres niveles (bajo, medio, alto) funciona para programas de SGSI pequeños donde la velocidad importa más que la granularidad. Una matriz numérica 5×5, multiplicando probabilidad por impacto en una escala del uno al cinco, ofrece una priorización más fina y es el modelo que la mayoría de los auditores están acostumbrados a ver. Un modelo híbrido, que añade un factor de ponderación para la exposición regulatoria o el impacto reputacional sobre la puntuación base 5×5, es adecuado para organizaciones con obligaciones de cumplimiento complejas superpuestas al riesgo estándar de seguridad de la información. Nuestra plantilla de matriz de riesgos explica cómo construir la versión 5×5 con ejemplos de puntuación desarrollados.

La regla general: comienza con el modelo 5×5 a menos que tu organización sea lo suficientemente pequeña como para que una escala de tres niveles permita tomar las mismas decisiones con mayor rapidez. No construyas un modelo híbrido ponderado hasta que la versión más sencilla haya demostrado ser demasiado poco precisa en la práctica.

Los umbrales de apetito de riesgo convierten las puntuaciones en acciones. Define, de antemano, la puntuación a partir de la cual un riesgo debe escalarse a la dirección en lugar de cerrarse a nivel operativo. Un patrón habitual establece un techo numérico en las puntuaciones de riesgo que activa la escalada automática a un comité de riesgos o a un patrocinador ejecutivo, independientemente de quién lo haya identificado. Sin un umbral escrito, la escalada se convierte en una decisión subjetiva que varía según quién esté en la sala.

Una vez tomada la decisión de tratamiento, el mapeo al Anexo A es el paso final, y es donde el pensamiento de lista de verificación causa más daño. ISO/IEC 27001 requiere que primero identifiques los controles necesarios a partir de la evaluación de riesgos y luego compruebes el Anexo A para encontrar una correspondencia, documentando la justificación de cualquier exclusión en la Declaración de Aplicabilidad. Las notas de práctica de los propios recursos del comité de ISO subrayan que el Anexo A es un conjunto de referencia, no una lista exhaustiva, y que los controles necesarios pueden proceder de otras normas. Nuestra guía de controles del Anexo A explica cómo evitar tratar el anexo como un ejercicio de marcado de casillas. Para orientación más detallada sobre cómo documentar la propia decisión de tratamiento, la responsabilidad y los plazos, consulta nuestra guía de tratamiento de riesgos.

Un ejemplo desarrollado y una plantilla con la que puedes empezar hoy

El consejo abstracto sobre esquemas solo llega hasta cierto punto. A continuación se presenta una fila completa, desarrollada desde la identificación hasta el riesgo residual, para una empresa de software de tamaño mediano.

El escenario: la plataforma de tickets de soporte al cliente, alojada por un proveedor SaaS externo, está expuesta a un ataque de relleno de credenciales que explota políticas de contraseñas débiles en las cuentas de los agentes de soporte, lo que resulta en la pérdida de confidencialidad de los tickets de soporte al cliente que contienen datos personales. El activo fue identificado durante las entrevistas con las partes interesadas porque los agentes de soporte tienen amplio acceso de lectura a todos los registros de clientes. La probabilidad se valoró como alta dado que en el momento de la revisión no se exigía autenticación multifactor; el impacto se valoró como alto porque el activo contiene datos personales regulados. La decisión de tratamiento fue implementar autenticación multifactor para todas las cuentas de agentes en un plazo de 30 días, bajo la responsabilidad del responsable de seguridad de TI. Tras el tratamiento, el riesgo residual descendió a bajo, porque los ataques de relleno de credenciales son sustancialmente más difíciles de ejecutar contra cuentas protegidas por un segundo factor.

Para los lectores que construyen desde cero, una plantilla de hoja de cálculo inicial con estas columnas ya incorporadas es la forma más rápida de comenzar, y una versión lista para auditoría añade la columna de vínculo al RDR y una pestaña de historial de versiones. Los equipos que planeen alimentar una plataforma GRC más adelante deben mantener los encabezados de columna alineados con el esquema anterior, ya que la coincidencia de nombres de campo es lo que hace que una importación posterior sea sencilla en lugar de un ejercicio de reasignación manual. Los equipos pequeños pueden gestionar todo el registro en una sola hoja; las organizaciones más grandes que agregan datos de distintas unidades de negocio acabarán necesitando que el registro de cada unidad se consolide en un resumen a nivel empresarial, lo que la sección de alineación con NIST más adelante cubre con más detalle.

Mantener el registro activo: cadencia, responsabilidad e informes

Un registro construido una vez y que nunca se revisa es peor que no tener ninguno, porque genera una falsa sensación de seguridad. La cadencia de revisión debe combinar una revisión periódica programada, generalmente trimestral para la mayoría de las organizaciones, con revisiones activadas por cambios siempre que entre en funcionamiento un nuevo sistema, cambie un proveedor importante o un incidente revele una brecha que el registro no había recogido.

1. Asigna a cada fila de riesgo un responsable nombrado que sea accountable de mantenerla actualizada, no un departamento o nombre de equipo.
2. Vincula cada fila del registro a su Registro de Detalle de Riesgo y a cualquier ticket abierto o tarea de remediación que haga seguimiento del tratamiento.
3. Mantén la vista ejecutiva en un resumen breve: riesgos por encima del umbral de apetito, sus responsables y fechas objetivo, en lugar del registro técnico completo.
4. Haz seguimiento de un pequeño conjunto de KPIs: tiempo medio hasta el tratamiento para los riesgos de mayor puntuación, el porcentaje de riesgos altos con un responsable nombrado y un plazo activo, y la tendencia en las puntuaciones de riesgo residual a lo largo de trimestres sucesivos.
5. Vuelve a puntuar cualquier riesgo cuyo control subyacente cambie, en lugar de esperar al próximo ciclo de revisión programado.

Estos KPIs importan porque un registro con docenas de riesgos altos abiertos y sin evolución durante tres trimestres cuenta una historia muy diferente a un auditor que uno que muestra un descenso constante del riesgo residual. La línea de tendencia suele ser más persuasiva que cualquier fila individual.

Alinear tu registro con el modelo de reporte de riesgos empresariales de NIST

ISO 27001 no prescribe un formato de registro específico, lo cual es exactamente la razón por la que alinearse con un esquema establecido resulta beneficioso. La revisión de diciembre de 2025 de NIST de sus publicaciones sobre ciberseguridad y gestión de riesgos empresariales recomienda que los registros de riesgos de ciberseguridad capturen, como mínimo, el escenario de riesgo, el mapeo de amenazas y vulnerabilidades, la probabilidad, el impacto, la decisión de tratamiento, el propietario del riesgo y el riesgo residual, lo que se corresponde casi campo por campo con el esquema recomendado anteriormente en este artículo.

La contribución real del modelo NIST es la separación entre el Cybersecurity Risk Register (CSRR) y el Risk Detail Record (RDR). La NIST IR 8286A proporciona una plantilla notional de CSRR junto con un esquema de RDR, diseñados explícitamente para mantener el CSRR conciso para la revisión de gestión mientras se preserva la profundidad técnica que los auditores necesitan en un registro vinculado. La NIST IR 8286B amplía esto con ejemplos de esquema JSON para reportes de riesgos legibles por máquina, lo que cobra importancia cuando se agregan datos de riesgo de múltiples unidades de negocio o se alimenta una plataforma GRC.

Adoptar esta estructura conlleva tres beneficios prácticos:

• Un CSRR conciso es lo que ejecutivos y auditores realmente leen, mientras que el RDR preserva la evidencia sin saturar la vista de resumen.
• Los nombres de campo estandarizados que se mapean a los esquemas de NIST hacen que una migración posterior a un proceso de agregación empresarial sea mucho menos costosa.
• Asignar un ID de riesgo canónico único por escenario, nunca duplicado entre unidades de negocio, es lo que hace posible la consolidación a nivel empresarial sin reconciliación manual.

No es necesario adoptar el esquema JSON completo de NIST para beneficiarse de este enfoque. Incluso una hoja de cálculo que separa las filas de resumen de una pestaña de detalle vinculada captura la mayor parte del valor.

Lo que los auditores señalan realmente cuando examinan un registro

Tres fallos aparecen una y otra vez cuando un registro se muestrea durante una auditoría. El primero son las descripciones de riesgo vagas, entradas como "riesgo cibernético en sistemas de TI" que no le dan al auditor nada que rastrear hasta un activo o decisión de control concretos. El segundo son los responsables ausentes o desactualizados, filas asignadas a un rol que ya no existe o a una persona que abandonó la empresa hace ocho meses. El tercero son las acciones de tratamiento sin fecha objetivo, lo que se interpreta como un riesgo que todos reconocen pero que nadie se ha comprometido a solucionar.

La solución para los tres es la misma disciplina: redactar los escenarios en frases completas, revisar la responsabilidad cada trimestre independientemente de si ha cambiado algo más, y no dejar nunca que una acción de tratamiento permanezca en el registro sin una fecha asociada. Un registro que tanto un ingeniero de seguridad como un director financiero puedan leer sin traducción está cumpliendo su función. Mantén el detalle técnico en el registro vinculado, y la fila de resumen en un lenguaje que un directivo no técnico pueda interpretar en una sola lectura.

Los auditores que he visto avanzar más rápido por un registro son aquellos en que cada fila enlaza directamente a una evidencia: un ticket, un resultado de análisis, una excepción firmada. Ese único hábito ahorra más tiempo de auditoría que cualquier decisión de formato.

— Martin

ISMS Calculator: validar las estimaciones de esfuerzo y plazos de tu registro

Construir el registro responde a qué necesita tratamiento. No te dice cuánto costará ese tratamiento ni cuánto tiempo lleva realmente ejecutar un programa ISO 27001, que es la brecha que cubre ISMS Calculator. La verificación gratuita de 2 minutos ofrece una lectura instantánea de preparación antes de comprometerse con una evaluación completa, y la Calculadora de Costes ISO 27001 produce una estimación en tiempo real específica para tu organización basada en el tamaño de la empresa, el sector y la madurez de seguridad actual, con supuestos editables que puedes ajustar a medida que el registro se rellena.

Si tu registro ya lista una docena de acciones de tratamiento de alta prioridad con fechas objetivo, la calculadora ayuda a verificar esos plazos comparándolos con referencias del modelo en lugar de estimar el esfuerzo de forma aislada. También produce una evaluación de madurez a lo largo de los cuatro temas de control del Anexo A, lo que te permite ver dónde la cobertura de tu registro es escasa antes de que lo haga un auditor, y exporta los resultados como un informe PDF compartible para la revisión de gestión. Para un diagnóstico más profundo una vez que tu registro esté en forma, la Evaluación de Preparación ISO 27001 va más allá de la verificación inicial. Comienza con la verificación gratuita y comprueba dónde se sitúa tu estimación de esfuerzo actual.

Fuentes primarias y plantillas

La serie NIST IR 8286, incluidas IR 8286A e IR 8286B, publica los esquemas CSRR y RDR referenciados a lo largo de esta guía, junto con el aviso de NIST de diciembre de 2025 sobre la integración de la ciberseguridad y la gestión de riesgos empresariales. La página oficial de la norma ISO/IEC 27001:2022 recoge los requisitos de la Cláusula 6.1.3 y el Anexo A en los que se basa este artículo. Las organizaciones que conectan las filas del registro con evidencias de respuesta a incidentes también pueden consultar la guía de respuesta a incidentes de Netverge para obtener ejemplos prácticos de vinculación con el RDR.

Fuentes

• NIST revisa las publicaciones que integran ciberseguridad y riesgo empresarial
• Priorización del riesgo de ciberseguridad para la gestión de riesgos empresariales (actualización NIST IR 8286B)
• IR 8286A: Identificación y estimación del riesgo de ciberseguridad para la gestión de riesgos empresariales (NIST)
• ISO/IEC 27001:2022 - Sistemas de gestión de la seguridad de la información

Preguntas frecuentes

¿Es un requisito legal disponer de un registro de riesgos?

ISO/IEC 27001 no utiliza el término "requisito legal" para un registro de riesgos, pero la Cláusula 6.1.3 exige un proceso documentado de evaluación y tratamiento de riesgos, y un registro es la forma estándar en que las organizaciones producen esa evidencia. Sin él, la certificación frente a ISO 27001 no es alcanzable, ya que los auditores necesitan un registro trazable que vincule los riesgos con las decisiones de control.

¿Cómo se lleva a cabo una evaluación de riesgos ISO 27001?

Una evaluación de riesgos ISO 27001 comienza con un inventario de activos completo, luego identifica amenazas y vulnerabilidades frente a cada activo para construir escenarios de riesgo estructurados, y puntúa cada uno en función de la probabilidad y el impacto según criterios definidos. Nuestra guía de metodología de evaluación de riesgos cubre la secuencia completa, desde la clasificación de activos hasta la decisión de tratamiento, con mayor profundidad.

¿Existe alguna lista de verificación ISO 27001 gratuita disponible?

Las listas de verificación y plantillas iniciales gratuitas para registros de riesgos ISO 27001 son ampliamente accesibles, aunque la calidad varía significativamente en cuanto a si incluyen los campos que los auditores realmente esperan encontrar, como el responsable, la fecha objetivo y el riesgo residual. ISMS Calculator ofrece una verificación de preparación gratuita de 2 minutos que proporciona una lectura instantánea de brechas sin necesidad de registro.

¿Cómo se construye un registro de riesgos desde cero?

Comienza con un inventario de activos limpio que incluya responsable, clasificación y mapeo del proceso de negocio para cada entrada, ya que sin ello no es posible redactar escenarios de riesgo. A partir de ahí, redacta escenarios de riesgo estructurados que nombren el activo, la amenaza, la vulnerabilidad y el impacto en el negocio, puntúa cada uno por probabilidad e impacto, y asigna un responsable de tratamiento y una fecha objetivo a cada fila cuya puntuación supere el umbral de apetito de riesgo definido.

¿Cuál es la diferencia entre un CSRR y un Registro de Detalle de Riesgo?

Un Cybersecurity Risk Register (CSRR) contiene filas de resumen concisas destinadas a la revisión de gestión y auditoría, mientras que un Risk Detail Record (RDR) contiene la evidencia técnica subyacente, como resultados de análisis y tickets de remediación, vinculada a cada fila del CSRR. Esta separación, descrita en la NIST IR 8286A, mantiene el registro legible mientras preserva el detalle con nivel de auditoría en otro lugar.

Recomendado

• Matriz de riesgos ISO 27001: plantilla 5×5 para seguridad de la información lista para auditoría
• Tratamiento de riesgos ISO 27001: una guía lista para auditores
• Guía de documentación del SGSI lista para auditoría en ISO 27001