La evaluación de riesgos es el documento sobre el que ISO 27001 construye todo lo demás, y el que más a menudo se compra como plantilla de hoja de cálculo con los riesgos de otro dentro. El apartado 6.1.2 no pide una plantilla; pide un proceso que produzca cinco cosas: criterios de riesgo, tanto para aceptar riesgos como para realizar evaluaciones; una identificación de los riesgos de seguridad de la información, con sus propietarios; un análisis de las consecuencias potenciales y de la probabilidad realista, que da un nivel; una evaluación frente a los criterios, con los riesgos priorizados para el tratamiento; y resultados consistentes, válidos y comparables de una evaluación a la siguiente. El apartado 6.1.3 continúa con el tratamiento: las opciones, los controles necesarios, la comparación con el anexo A para que nada necesario haya quedado fuera, la declaración de aplicabilidad, y el plan de tratamiento de riesgos aprobado por los propietarios de los riesgos con su aceptación del riesgo residual. Este artículo lee los dos apartados para una empresa de software y describe el método que la página gratuita usa para redactar el registro y el plan, frente a los 93 controles que el paquete mantiene como datos y los riesgos de partida que el producto siembra el primer día.

Un método que la norma le deja a usted

ISO 27001 exige criterios y un proceso repetible; no exige una escala concreta, un mapa de calor ni una fórmula, e ISO/IEC 27005 da orientación en lugar de reglas. El método de StandardOS, enunciado en el documento que redacta, es deliberadamente pequeño: probabilidad puntuada de 1 a 5, impacto puntuado de 1 a 5, el nivel como su producto de 1 a 25, cuatro bandas (bajo hasta 4, medio hasta 9, alto hasta 15, crítico por encima) y un umbral de aceptación que la empresa elige, por defecto 4, de modo que un riesgo en el umbral o por debajo se retiene con un responsable nombrado y un riesgo por encima se trata. Una escala de cinco puntos basta para que un auditor vea que dos evaluaciones del mismo riesgo con un año de diferencia son comparables, y es lo bastante pequeña para que un equipo de diez personas puntúe veinte riesgos en una hora. Lo que hace defendible el método no son los números sino la consistencia: los mismos criterios escritos, la misma escala para cada riesgo, el mismo umbral y la misma firma del propietario sobre el riesgo residual.

Los riesgos de partida que lleva una empresa de software

El paso de identificación es donde una plantilla más engaña, porque los riesgos de una plantilla son los de otro. Los riesgos de una empresa de software se conocen sin embargo en gran parte antes del primer taller, y la página gratuita parte del conjunto que el producto siembra: un phishing que compromete una credencial, un portátil perdido o robado, la indisponibilidad de un servicio de nube crítico, una copia de seguridad que no se restaura, un empleado que se va y cuyo acceso sigue abierto, equipos desechados con datos dentro, una brecha en un proveedor o en el proveedor de nube, un incidente no detectado o no notificado a tiempo, un requisito legal o contractual pasado por alto, responsabilidades de seguridad sin propietario, personas que entran o salen sin los fundamentos de seguridad, información compartida de forma insegura; y, cuando las respuestas lo dicen, una vulnerabilidad introducida en el propio software de la empresa, código escrito por un proveedor que llega a producción sin revisión, una divulgación no autorizada de datos personales y un acceso físico no autorizado a las instalaciones. Cinco respuestas eligen el conjunto: cuántas personas, si la empresa desarrolla software, si externaliza el desarrollo, si tiene instalaciones, si trata datos personales de clientes. Cada riesgo de partida viene con una probabilidad, un impacto y los controles del anexo A que lo tratan, todo editable, y un riesgo que no aplica se elimina; un riesgo que falta en el conjunto se añade con sus propios controles.

Del plan a la declaración de aplicabilidad

El apartado 6.1.3 convierte el registro en decisiones. Para cada riesgo por encima del umbral la empresa elige una opción: modificar el riesgo con controles, retenerlo, evitar la actividad, o compartirlo con una aseguradora o un proveedor; para un riesgo modificado nombra los controles, y la unión de esos controles es lo que la declaración de aplicabilidad lleva después como aplicable. Por eso los dos documentos tienen que redactarse en este orden: una declaración que nombra A.8.13 como aplicable sin un riesgo de que una copia de seguridad no se restaure no tiene justificación para la fila, y un registro que trata ese riesgo sin A.8.13 no tiene control para él. La página gratuita redacta las dos direcciones: el plan enumera los controles que cada riesgo tratado nombra, y la última sección del documento enumera cada control que el plan nombra, que es la entrada de la declaración de aplicabilidad redactada en la página siguiente, control por control.

Propietarios, aceptación y el intervalo

Dos cosas que un auditor lee antes que las puntuaciones son la columna de propietarios y la aceptación. Cada riesgo tiene un propietario (apartado 6.1.2 c) 2)), y cada riesgo residual lo acepta su propietario (6.1.3 f)), y por eso la página mantiene un campo de responsable por fila y escribe "aún sin nombrar" donde está vacío en lugar de dejar la celda en blanco. El umbral de aceptación es una decisión de la dirección, y una empresa que lo sube de 4 a 9 para acortar el plan debe esperar la pregunta de por qué se retiene un riesgo de alta probabilidad e impacto moderado. El apartado 8.2 hace después repetir la evaluación a intervalos planificados o cuando se proponen u ocurren cambios significativos: una nueva superficie de producto, una nueva región de alojamiento, un nuevo subencargado, un nuevo equipo. El enlace que la página escribe lleva las respuestas, el umbral y las puntuaciones de cada riesgo de partida en la dirección, de modo que una versión es un enlace que puede guardarse y compararse con el siguiente.

Qué hacer con ello

Responda las cinco preguntas y lea los riesgos de partida frente a su propio producto, eliminando los que no aplican y añadiendo los que faltan en el conjunto. Puntúe cada uno con la escala de cinco puntos, fije el umbral, nombre un responsable por fila y elija la opción para cada riesgo por encima de la línea. Copie el documento, féchelo, haga que los propietarios acepten los riesgos residuales y lleve la lista de controles de su final a la declaración de aplicabilidad. 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, y convierte cada tratamiento en una posición de la declaración; la página de costes dice cuántos días de auditor compra el alcance, y la guía de controles lo que pide cada control que el plan nombra.