Una matriz de riesgos documentada, normalmente una cuadrícula 5×5 que puntúa la probabilidad frente al impacto, es un método aceptable y práctico para priorizar los riesgos de seguridad de la información en el marco de ISO 27001. Los auditores no se preocupan de si se utiliza una matriz 5×5 o 4×4; lo que les importa es que la metodología esté documentada, se aplique de forma coherente y sea trazable hasta los controles del Annex A y la Declaración de Aplicabilidad. Si se cumplen estos tres requisitos, la propia matriz es la parte más sencilla.
Resumen ejecutivo:
- Una matriz de riesgos 5×5 documentada es suficiente para la conformidad con ISO 27001 si está claramente definida, se aplica de forma coherente y es trazable hasta los controles y la declaración de aplicabilidad.
- Elegir escalas y niveles adecuados —habitualmente entre 4×4 y 5×5— equilibra la granularidad con la consistencia entre evaluadores, especialmente cuando los criterios de impacto se adaptan a los riesgos específicos del sector.
- El proceso de evaluación de riesgos debe especificar el tamaño de la matriz, las definiciones de probabilidad e impacto, los criterios de aceptación del riesgo, la frecuencia de evaluación, el propietario del riesgo y la identificación de amenazas y vulnerabilidades, con actualizaciones periódicas tras cambios significativos.
- La puntuación debe centrarse en el riesgo inherente antes de los controles; el riesgo residual se utiliza para justificar la eficacia de los controles y las decisiones de tratamiento alineadas con los umbrales de aceptación documentados.
- Los planes de tratamiento del riesgo y los mapeos de controles del Annex A requieren una trazabilidad precisa hasta los riesgos, con aprobaciones de dirección documentadas para el riesgo residual por encima de los umbrales de aceptación, a fin de satisfacer los requisitos de auditoría.
Tabla de Contenidos
- ¿Qué es una Matriz de Riesgos ISO 27001 y Cuándo Utilizarla?
- Elección de Escalas y Diseño de la Matriz: 5×5, 4×4 y Más Allá
- Construcción de la Matriz Paso a Paso según la Cláusula 6.1.2
- Convertir Puntuaciones en Decisiones de Tratamiento y un Mapeo con el Annex A
- Estructuración del Registro de Riesgos y el Plan de Tratamiento
- Una Matriz 5×5 Trabajada que Puede Adaptar
- Dónde las Calculadoras y los Benchmarks Resultan Realmente Útiles
- Preparar la Matriz para la Auditoría: Qué Marca Realmente la Diferencia
- Elimine las Conjeturas de las Hojas de Cálculo con Ismscalculator
- Fuentes Primarias y Lecturas Adicionales
- Fuentes
¿Qué es una Matriz de Riesgos ISO 27001 y Cuándo Utilizarla?
Una matriz de riesgos ISO 27001 es una cuadrícula que representa la probabilidad en un eje y el impacto en el otro, generando un mapa de calor que clasifica los riesgos de insignificante a crítico. Al multiplicar las dos puntuaciones se obtiene un valor de riesgo que puede ordenarse, compararse y monitorizarse a lo largo del tiempo. Es la misma lógica que los gestores de proyectos han utilizado durante décadas, adoptada y formalizada para el trabajo de seguridad de la información.
La matriz ocupa su lugar en un programa ISO 27001 porque obliga a puntuar cada riesgo con el mismo criterio. Sin esa disciplina, un propietario de riesgo califica un escenario de phishing como "alto" basándose en la intuición, mientras que otro califica un escenario casi idéntico como "medio" porque tuvo una buena semana. Una matriz con niveles definidos elimina esa inconsistencia, o al menos la reduce a algo defendible.
La puntuación del impacto se corresponde de forma natural con la tríada CIA: confidencialidad, integridad y disponibilidad. Un escenario de ransomware, por ejemplo, afecta gravemente a la disponibilidad (los sistemas se caen) y puede comprometer también la integridad (los datos se corrompen antes de que se detecte el problema). Un bucket de almacenamiento en la nube mal configurado es casi exclusivamente un fallo de confidencialidad. Puntuar las tres dimensiones, en lugar de un único número combinado de "qué tan grave es esto", mantiene la honestidad del registro de riesgos respecto a lo que realmente falla cuando se materializa una amenaza.
Las matrices no son el único método de evaluación de riesgos que permite ISO 27001. La norma es explícita en que no prescribe una técnica concreta. Los modelos cuantitativos basados en la pérdida anual esperada, las simulaciones de Monte Carlo y FAIR (Factor Analysis of Information Risk) satisfacen igualmente la misma cláusula. Entonces, ¿por qué la mayoría de las organizaciones, especialmente las pequeñas y medianas, acaban optando por una matriz?
- Escala con un inventario de activos en crecimiento sin exigir conocimientos estadísticos a cada propietario de riesgo.
- Produce resultados que las partes interesadas no técnicas y los auditores pueden interpretar de un vistazo.
- Es repetible a lo largo de las revisiones anuales, lo que importa más a un organismo de certificación que la precisión bruta.
- Es barata de construir y mantener en comparación con modelos cuantitativos que necesitan datos históricos de pérdidas que la mayoría de las empresas no poseen.
Elija una matriz cuando su cartera de riesgos sea amplia (decenas o cientos de escenarios en TI, RRHH, seguridad física y terceros) y necesite un método que un responsable de cumplimiento, un gestor de TI y un auditor externo puedan interpretar de la misma manera. Reserve el modelado cuantitativo para los pocos riesgos de alto impacto en los que la dirección quiera una cifra monetaria asociada a la exposición.
Elección de Escalas y Diseño de la Matriz: 5×5, 4×4 y Más Allá
La matriz 5×5 (cinco niveles de probabilidad por cinco niveles de impacto, puntuados del 1 al 5 en cada eje) es el estándar de facto en la mayoría de las implantaciones de ISO 27001, y con razón. Un enfoque 5×5 documentado con bandas de aceptación definidas ofrece a los auditores exactamente lo que buscan: suficiente granularidad para diferenciar los riesgos de forma significativa, sin tantos niveles que dos evaluadores no puedan ponerse de acuerdo sobre dónde situar un escenario.
Las escalas numéricas (del 1 al 5) y las escalas etiquetadas (raro, improbable, posible, probable, casi seguro) funcionan ambas, pero resuelven problemas distintos. Las escalas numéricas se multiplican limpiamente en una única puntuación de riesgo, que es lo que esperan la mayoría de los mapas de calor y registros de riesgos. Las escalas etiquetadas se leen mejor en presentaciones para la dirección, pero necesitan una tabla de conversión a números antes de poder ordenar nada. La mayoría de los programas maduros utilizan ambas: etiquetas para el relato, números para el cálculo.
A continuación se describe un proceso sencillo para elegir y definir la escala:
- Decida primero el tamaño de la matriz. Una 5×5 funciona para la mayoría de las organizaciones de tamaño medio; una 4×4 es más adecuada para equipos más pequeños que tienen dificultades para distinguir con confianza cinco gradaciones de cualquier cosa.
- Redacte una definición de una sola frase para cada nivel en ambos ejes. "Probabilidad 3: podría ocurrir razonablemente una vez en los próximos 12 meses según datos de incidentes del sector o eventos internos pasados" supera siempre a "moderado" cuando un auditor pide a un propietario de riesgo que justifique una puntuación.
- Ancle los criterios de impacto a consecuencias empresariales, no solo técnicas. Los umbrales de pérdida financiera, la exposición a sanciones regulatorias, las penalizaciones contractuales y los umbrales de horas de interrupción traducen el riesgo técnico al lenguaje que la dirección realmente aprueba.
- Pruebe la escala con diez riesgos reales antes de implantarla. Si tres evaluadores distintos puntúan el mismo escenario con dos niveles de diferencia, sus definiciones son demasiado vagas.
- Consolide la escala en su documento de metodología de riesgos y cámbiela únicamente mediante una revisión formal, nunca a mitad de ciclo.
La disyuntiva con la que lidia todo equipo es la granularidad frente a la consistencia. Una matriz 7×7 parece impresionantemente precisa sobre el papel, pero pida a cinco propietarios de riesgo que distingan de forma independiente "probabilidad 4" de "probabilidad 5" en 49 celdas y obtendrá más desacuerdo que datos. Las escalas más gruesas sacrifican matices, pero ganan algo más valioso durante una auditoría: evaluadores que aplican los criterios de la misma manera en cada ocasión.
Consejo profesional: Adapte su escala de impacto a su sector antes de adaptar cualquier otra cosa. El nivel de impacto "crítico" de un proveedor sanitario debería hacer referencia a la seguridad del paciente y a la exposición a la normativa aplicable; el de una aseguradora debería hacer referencia a los datos de los tomadores de pólizas y los requisitos de capital regulatorio. Una escala genérica copiada de una plantilla rara vez se corresponde con lo que realmente preocupa a su consejo de administración.
Construcción de la Matriz Paso a Paso según la Cláusula 6.1.2
La cláusula 6.1.2 de ISO/IEC 27001 exige definir y aplicar un proceso documentado de evaluación de riesgos de seguridad de la información, incluyendo los criterios de aceptación del riesgo y los criterios para realizar las propias evaluaciones. Este único requisito impulsa casi todo lo que un auditor verifica posteriormente, por lo que conviene tratarlo como una lista de comprobación, no como una sugerencia.
Antes de puntuar un solo riesgo, su metodología documentada debe especificar:
- El tamaño de la matriz y la definición de cada nivel de probabilidad e impacto.
- Los criterios de aceptación del riesgo (la puntuación a partir de la cual un riesgo requiere tratamiento, no solo seguimiento).
- La frecuencia de evaluación (anual es el estándar; con mayor frecuencia en entornos de alta variabilidad).
- Quién es el responsable del proceso, quién es el propietario de cada riesgo y quién aprueba las decisiones de aceptación.
- Cómo se identificarán los activos, las amenazas y las vulnerabilidades.
Este último punto merece atención propia, porque es donde muchos equipos que implantan un SGSI por primera vez se quedan bloqueados. Comience con un inventario de activos —información, sistemas, personas, instalaciones, terceros— y trabaje hacia afuera. Para cada activo, realice una identificación basada en escenarios: ¿qué podría salir mal de forma realista y qué par amenaza/vulnerabilidad lo provoca? Un parque de portátiles combina la amenaza "robo" con la vulnerabilidad "discos sin cifrar". Una base de datos de clientes combina "inyección SQL" con "código de aplicación sin parchear". No se necesitan marcos de modelado de amenazas sofisticados en esta fase; una lluvia de ideas estructurada sobre el inventario de activos, contrastada con un catálogo de amenazas, cubre la mayoría de las organizaciones.
Una vez identificado un escenario, la puntuación sigue una fórmula sencilla: riesgo inherente = probabilidad × impacto, calculado como si no existiera ningún control. Esto importa porque establece una línea de base. Si se puntúa directamente teniendo en cuenta los controles, se subestimará sistemáticamente la exposición real y no habrá forma de demostrar la eficacia de los controles posteriormente.
El riesgo residual es donde entran en juego los controles existentes. Si ya se ha implantado autenticación multifactor y detección de amenazas en los endpoints de ese parque de portátiles, la probabilidad de que un robo derive en una brecha de datos disminuye —quizás de 4 a 2—. Recalcule la puntuación con la misma fórmula y la diferencia entre el riesgo inherente y el residual se convierte en la evidencia de que los controles están aportando algo medible. Esta diferencia es también lo que la mayoría de los responsables de cumplimiento infravaloran: es el artefacto más claro que puede entregar a un auditor para demostrar que sus controles no están meramente documentados, sino que funcionan.
Con una puntuación residual en mano, el paso de evaluación es una comparación, no un juicio subjetivo: ¿la puntuación residual está por encima o por debajo de los criterios de aceptación documentados? Si está por debajo, puede aceptar el riesgo y continuar. Si está por encima, se elige una vía de tratamiento; las opciones de tratamiento habituales se dividen en cuatro categorías:
- Mitigar mediante la implantación de controles adicionales del Annex A.
- Transferir la exposición mediante seguros o externalización.
- Evitar el riesgo interrumpiendo la actividad que lo genera.
- Aceptar la exposición residual, documentada y formalmente aprobada por la alta dirección.
Cada una de estas decisiones necesita un rastro documental. Un método de matriz documentado y repetible reduce los hallazgos de auditoría no porque algún modelo de puntuación en particular sea superior, sino porque los auditores verifican la coherencia y la evidencia, no la elegancia matemática. La entrada en el registro de riesgos, el registro de aprobación y las notas de revisión son lo que realmente se inspecciona. La matriz es simplemente el mecanismo que generó el número.
Convertir Puntuaciones en Decisiones de Tratamiento y un Mapeo con el Annex A
Una puntuación de riesgo no significa nada hasta que se decide qué hacer por encima y por debajo de ella. La mayoría de las organizaciones establecen tres o cuatro bandas de aceptación; algo como: puntuaciones de 1 a 4 son bajas y se monitorizan, de 5 a 9 son medias y se revisan en el siguiente ciclo, de 10 a 15 son altas y requieren un plan de tratamiento en 90 días, y de 16 a 25 son críticas y exigen acción en 30 días junto con notificación inmediata a la dirección.
Esos umbrales exactos no son sagrados. Lo que importa es que se establezcan antes de comenzar a puntuar los riesgos, que se incorporen a la metodología y que se apliquen sin excepción. Un error habitual es ajustar la línea de aceptación a posteriori porque el riesgo de un proyecto favorito quedó justo por encima de ella. Ese tipo de racionalización retrospectiva es exactamente lo que aparece como no conformidad cuando un auditor rastrea las decisiones hasta los criterios documentados.
Una vez que un riesgo supera el umbral de tratamiento, el siguiente paso es mapearlo con el Annex A. El Annex A de ISO 27001 incluye 93 controles agrupados en cuatro temáticas: organizativos, de personas, físicos y tecnológicos. Para cada riesgo alto o crítico, se seleccionan el control o los controles que lo abordan, y se registra esa selección —junto con la justificación de su inclusión o exclusión— en la Declaración de Aplicabilidad.
La SoA es donde muchos programas de SGSI, por lo demás sólidos, pierden puntos. Los auditores esperan trazabilidad desde cada control del Annex A hasta al menos un riesgo en el registro, y una discrepancia entre ambos es una de las no conformidades más frecuentemente citadas en las auditorías de certificación. Si la SoA indica que A.8.24 (uso de criptografía) es aplicable, pero el registro de riesgos nunca menciona un escenario que la criptografía mitigaría, eso es una brecha que un auditor detectará de inmediato.
La solución es procedimental, no ingeniosa: construya la SoA directamente a partir del registro de riesgos, y no como un ejercicio separado. Para cada riesgo que haya requerido tratamiento, anote qué control (o controles) del Annex A está implantando y haga una referencia cruzada con el ID de riesgo en la columna de justificación de la SoA. Trabajar en sentido inverso —rellenando justificaciones para una plantilla SoA genérica— es como se produce la brecha de trazabilidad.
Las verificaciones de los auditores en este ámbito suelen seguir un patrón predecible:
- Seleccionan varios riesgos del registro calificados como altos o críticos y solicitan ver la entrada correspondiente en la SoA.
- Seleccionan varios controles "aplicables" de la SoA y preguntan qué riesgo motivó esa selección.
- Comprueban si los controles excluidos tienen una justificación documentada vinculada a un hallazgo real de la evaluación de riesgos, no simplemente una plantilla genérica de "no aplicable a nuestro contexto".
- Confirman que las aceptaciones de riesgo residual por encima del umbral documentado llevan la aprobación de la dirección, con fecha y atribuida a un aprobador nombrado.
Este último punto sorprende a más organizaciones de lo que debería. Si los criterios de aceptación establecen que cualquier puntuación superior a 15 requiere la aprobación de la alta dirección, y existe un riesgo con puntuación 20 en el registro sin firma adjunta, eso no es un detalle de documentación menor. Es una ruptura en la cadena de responsabilidad sobre la que se construye toda la norma.
Estructuración del Registro de Riesgos y el Plan de Tratamiento
El registro de riesgos es el documento de trabajo en el que converge todo lo demás del proceso, y debe contener más que una descripción del riesgo y una puntuación. Como mínimo, incluya columnas para:
- Un ID único de riesgo (para referencias cruzadas en la SoA y el plan de tratamiento)
- Descripción del riesgo y el activo afectado
- Par amenaza/vulnerabilidad que crea el escenario
- Probabilidad inherente, impacto inherente y puntuación inherente
- Controles existentes ya implantados
- Probabilidad residual, impacto residual y puntuación residual
- Decisión de tratamiento (mitigar, transferir, evitar, aceptar)
- Propietario del riesgo (una persona nominada, no un departamento)
- Estado y fecha de la próxima revisión
El campo del propietario del riesgo merece una pausa. "El departamento de TI" no es un propietario del riesgo; es una entrada en el organigrama sin ninguna responsabilidad asociada. Los auditores han comenzado a preguntar expresamente quién es el responsable personal del seguimiento de un riesgo determinado hasta su cierre, y "el departamento de TI" no supera esa pregunta. Nombre a una persona.
Para cada riesgo que supere el umbral de aceptación, la entrada en el registro debe derivar en un plan de tratamiento con su propia estructura: el control específico que se va a implantar, una fecha de hito, la persona que validará que el control realmente funciona una vez desplegado (no solo que fue instalado) y la evidencia de esa validación —capturas de pantalla, resultados de pruebas, aprobación de una política, lo que corresponda según el tipo de control—.
La cadencia de revisión debe ajustarse al ritmo de cambio del entorno de riesgos. Las revisiones completas anuales son la base que todos realizan, pero un SGSI realmente maduro también activa revisiones ad hoc tras eventos relevantes: la puesta en marcha de un nuevo sistema, una adquisición, un incidente significativo o un nuevo requisito regulatorio que aterriza en el escritorio. Esperar un año completo para reevaluar los riesgos tras un cambio material en el entorno es una brecha que los auditores detectan rápidamente, porque sugiere que el proceso de riesgos funciona según el calendario y no según las condiciones reales.
Consejo profesional: Mantenga un registro de cambios ligero junto al registro de riesgos —no enterrado en las actas de reuniones— que anote cada evento que haya activado una revisión fuera de ciclo y qué cambió como resultado. Transforma el "revisamos anualmente" en un patrón demostrable de monitorización continua, que es una historia de auditoría mucho más sólida que cualquier instantánea anual aislada.
Una Matriz 5×5 Trabajada que Puede Adaptar
A continuación se muestra un mapa de calor 5×5 estándar con la probabilidad en el eje vertical y el impacto en la parte superior. Multiplique los dos para obtener la puntuación de riesgo en cada celda.
| Probabilidad ↓ / Impacto → | 1 (Insignificante) | 2 (Menor) | 3 (Moderado) | 4 (Mayor) | 5 (Severo) |
|---|---|---|---|---|---|
| 1 (Raro) | 1 | 2 | 3 | 4 | 5 |
| 2 (Improbable) | 2 | 4 | 6 | 8 | 10 |
| 3 (Posible) | 3 | 6 | 9 | 12 | 15 |
| 4 (Probable) | 4 | 8 | 12 | 16 | 20 |
| 5 (Casi Seguro) | 5 | 10 | 15 | 20 | 25 |
Una estructura de bandas de uso habitual trata las puntuaciones de 1 a 4 como bajas, de 5 a 9 como medias, de 10 a 15 como altas y de 16 a 25 como críticas. Esas bandas son las que se documentarían en la metodología y se aplicarían de forma coherente a todo el registro.
A continuación se presenta una entrada completamente desarrollada que recorre todo el proceso:
Activo: Base de datos del sistema de gestión de relaciones con clientes (contiene nombres, datos de contacto e historial de compras). Amenaza/vulnerabilidad: Un atacante externo explota una vulnerabilidad de aplicación sin parchear para exfiltrar registros. Puntuación inherente: Probabilidad 4 (los sistemas sin parchear son un hallazgo recurrente en los análisis de vulnerabilidades) × Impacto 5 (sanciones regulatorias, costes de notificación de brechas, daño reputacional) = 20, crítico. Controles existentes e implantados: Firewall de aplicaciones web, ciclo trimestral de gestión de parches, cifrado en reposo, registro de accesos con alertas de anomalías. Puntuación residual: La probabilidad baja a 2 (los controles reducen significativamente la explotabilidad) × el impacto se mantiene en 4 (una brecha sigue siendo costosa aunque se contenga más rápidamente) = 8, medio. Decisión de tratamiento: Aceptar el riesgo residual con una revisión documentada cada seis meses, aprobada por el CISO, dado que ahora se sitúa dentro de la banda de aceptación media.
Adaptar esta plantilla a distintos sectores consiste principalmente en cambiar los criterios de impacto, no la mecánica de la matriz. Una aseguradora que puntúe el mismo escenario de base de datos ponderaría el impacto frente al capital regulatorio y las obligaciones de notificación a tomadores de pólizas, lo que a menudo eleva las puntuaciones de impacto más de lo que asignaría una empresa de comercio minorista para una brecha equivalente. Una empresa de cinco personas podría razonablemente utilizar una versión 4×4 de esta misma tabla si la 5×5 añade más granularidad de la que el equipo puede aplicar de forma coherente.
Dónde las Calculadoras y los Benchmarks Resultan Realmente Útiles
Las hojas de cálculo pueden gestionar perfectamente una matriz de riesgos, pero se quedan cortas en el momento en que se necesita comparar las puntuaciones de este año con las del año pasado, comparar la madurez con una referencia de modelo transparente, o exportar una SoA limpia sin tener que buscar errores de fórmula en cuarenta pestañas. Las herramientas diseñadas específicamente para este fin cubren esa brecha, y los datos de proveedores sobre software de evaluación de riesgos apuntan sistemáticamente a las mismas ventajas operativas: menos errores manuales, comparación de escenarios más rápida e informes que no requieren reconstruir tablas dinámicas cada trimestre.
Algunas funcionalidades marcan una diferencia real en la práctica:
- Calculadoras de preparación en tiempo real que estiman el coste y el esfuerzo de implantación en función del tamaño de la empresa y el sector.
- Evaluaciones de madurez que abarcan las cuatro temáticas de controles del Annex A, para saber dónde el programa es débil antes de que lo descubra el auditor.
- Exportaciones con plantilla que convierten directamente el registro de riesgos en documentación lista para la SoA.
- Evaluaciones guardadas y comparables, útiles cuando la dirección quiere ver el progreso a lo largo de varios trimestres.
Nada de esto reemplaza la metodología documentada que exige la cláusula 6.1.2, y ninguna herramienta firma la aceptación del riesgo residual en su nombre. Las herramientas agilizan la mecánica; el juicio, las asignaciones de propietarios y las aprobaciones de la dirección siguen siendo responsabilidad de su equipo.
Preparar la Matriz para la Auditoría: Qué Marca Realmente la Diferencia
La mayoría de los programas de SGSI que superan la certificación sin problemas no son los que tienen el modelo de puntuación más sofisticado. Son los que escribieron sus bandas de aceptación antes de puntuar un solo riesgo y nunca movieron los postes de meta en silencio con posterioridad. Esa única disciplina previene más no conformidades que cualquier nivel de sofisticación en la matriz.
La simplicidad supera a la precisión aquí con más frecuencia de lo que la gente espera. Una 5×5 limpia con niveles bien definidos, aplicada de la misma manera cada trimestre, tendrá mejor desempeño que un elaborado modelo 10×10 que tres propietarios de riesgo distintos interpretan de tres maneras diferentes. La coherencia es lo que los auditores pueden verificar realmente; la granularidad principalmente solo impresiona en una presentación.
El último elemento que los profesionales infravaloran es la cadencia vinculada a eventos reales, no al calendario. Un propietario nominado, una revisión activada por un cambio real en el entorno y un registro de lo que cambió entre evaluaciones cuentan una historia de auditoría mucho más sólida que cualquier instantánea anual pulida.
— Martin
Elimine las Conjeturas de las Hojas de Cálculo con Ismscalculator
Construir una matriz a mano funciona, pero determinar cuánto tiempo llevará todo el proyecto ISO 27001 y cuánto costará es un problema distinto para el que la mayoría de las hojas de cálculo nunca fueron diseñadas. Ismscalculator le ofrece una estimación en tiempo real adaptada al tamaño de su empresa, su sector y su madurez de seguridad actual, comparada con una referencia de modelo transparente.
La plataforma realiza una evaluación de madurez en las cuatro temáticas de controles del Annex A, para que pueda ver exactamente dónde se sitúan sus prácticas de gestión de riesgos antes de que lo descubra un auditor. A partir de ahí, un diagrama de Gantt personalizable diseña las fases de implantación, y puede exportar los hallazgos en PDF o guardar múltiples estimaciones para comparar escenarios a medida que el alcance evoluciona. Está diseñado para complementar el registro de riesgos y el plan de tratamiento que ya está elaborando, no para sustituir las decisiones de juicio que conlleva.
Comience con la evaluación de preparación gratuita de 2 minutos para obtener una estimación inicial, o realice la evaluación completa de preparación para ISO 27001 si está listo para trazar el coste, el calendario y el esfuerzo en detalle.
Fuentes Primarias y Lecturas Adicionales
Para el texto propio de la norma sobre los requisitos de evaluación de riesgos documentada, consulte directamente ISO/IEC 27001:2022. Para detalles orientados a la implantación y la auditoría, véase la guía de tratamiento de riesgos ISO 27001 y la guía metodológica completa.
Fuentes
- ISO/IEC 27001:2022 - Sistemas de gestión de la seguridad de la información
- Metodología de evaluación de riesgos ISO 27001: Guía completa
- ISO 27001:2022 GUÍA DE IMPLANTACIÓN DE SEGURIDAD DE LA INFORMACIÓN