El riesgo antes del incidente: MAGERIT y PILAR, la metodología que el Esquema Nacional de Seguridad da por supuesta

Idioma / Language: Español · English

Qué hay dentro del documento que toda auditoría pide y casi nadie lee

Toda auditoría de seguridad pregunta por un análisis de riesgos, todo informe pericial acaba tropezando con él y muy pocos profesionales del ámbito jurídico saben qué hay realmente dentro de ese documento. Monográfico de la metodología española de análisis y gestión de riesgos y de la herramienta con la que se aplica.

La pregunta que nadie hizo a tiempo

Cuando un incidente grave llega a un juzgado o a un expediente sancionador, la conversación deriva pronto hacia una pregunta que parece de sentido común: ¿la organización sabía que aquello podía ocurrir? De la respuesta depende buena parte del reproche. Una entidad que había identificado la amenaza, la había valorado y había decidido de forma motivada qué hacía con ella se encuentra en una posición muy distinta de la que no se había planteado nunca el asunto.

El documento donde esa respuesta debería estar por escrito se llama análisis de riesgos. En España, cuando se habla de sistemas de información del sector público, ese documento se elabora casi siempre con una metodología concreta, MAGERIT, y con una herramienta concreta, PILAR. Ambas se mencionan constantemente en auditorías, pliegos de contratación e informes periciales, y ambas resultan opacas para la mayoría de los profesionales del derecho y de la criminología que tienen que interpretar sus resultados.

Este artículo cierra el círculo que abrimos en la entrega anterior de esta serie. Allí comparábamos dos catálogos de bastionado —los CIS Benchmarks y las guías CCN-STIC— y señalábamos que ninguno de los dos resuelve la capa del riesgo. Esa capa es la que ocupamos ahora, con el propósito de que quien lea un análisis de riesgos sepa qué está leyendo, dónde suelen estar los defectos y qué puede y qué no puede concluirse a partir de él.

De dónde viene MAGERIT

MAGERIT es el acrónimo de Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. La elaboró el Consejo Superior de Administración Electrónica, órgano de la Administración General del Estado, y su primera versión data de 1997, en pleno despliegue de los servicios telemáticos de la Administración. La segunda versión llegó en 2006 y la tercera, que es la vigente, se publicó en octubre de 2012 bajo el Ministerio de Hacienda y Administraciones Públicas.

Esa fecha merece un comentario honesto de entrada. La versión 3 tiene ya más de una década y sigue siendo la referencia, sin que exista una versión 4 publicada. La actualización efectiva del método ha llegado por otras vías: por la evolución de la herramienta PILAR, que se mantiene con versiones anuales, por las guías CCN-STIC que la acompañan y por el propio Esquema Nacional de Seguridad, cuyo texto de 2022 obliga a un análisis de riesgos con un contenido determinado. Quien trabaje hoy con MAGERIT debe tener presente esa distancia temporal, sobre todo al modelar tecnologías que en 2012 tenían un peso muy distinto del que tienen ahora.

La metodología se publicó en tres libros que conviene distinguir, porque en la práctica se citan de forma imprecisa. El primero, el Método, contiene el procedimiento: qué pasos hay que dar, en qué orden y con qué resultados documentales. El segundo, el Catálogo de Elementos, es un inventario tipificado de clases de activos, de dimensiones de valoración, de criterios, de amenazas y de salvaguardas, pensado para que dos analistas distintos usen el mismo vocabulario. El tercero, la Guía de Técnicas, recoge herramientas analíticas de apoyo, desde el análisis mediante tablas hasta los árboles de ataque.

El diseño responde a una filosofía que conviene entender antes de criticarlo. MAGERIT es una metodología eminentemente cualitativa, construida para producir resultados comparables y auditables en organizaciones que no disponen de datos actuariales sobre incidentes. Ese enfoque tiene un coste en precisión y una ventaja decisiva en aplicabilidad, y explica muchas de las decisiones de diseño que a un economista o a un actuario le resultarían chocantes.

El vocabulario: activos, amenazas, salvaguardas, impacto y riesgo

Todo el edificio se sostiene sobre un puñado reducido de conceptos que conviene fijar con precisión, porque el uso coloquial de las mismas palabras genera enormes confusiones en los informes.

Un activo es cualquier elemento del sistema de información que tiene valor para la organización. El catálogo los tipifica en clases: la información y los servicios como activos esenciales, y después los datos, las claves criptográficas, las aplicaciones, el equipamiento físico, las comunicaciones, los soportes de información, el equipamiento auxiliar, las instalaciones y las personas. Esa tipificación no es un capricho taxonómico: cada clase tiene asociadas en el catálogo unas amenazas verosímiles y unas salvaguardas pertinentes, de modo que la clasificación correcta del activo determina buena parte del análisis posterior.

Una amenaza es un evento que puede ocurrirle a un activo y causar daño. El catálogo las agrupa en cuatro familias que resultan muy útiles para explicar el modelo a un tribunal: desastres naturales, sucesos de origen industrial, errores y fallos no intencionados, y ataques deliberados. Esa última familia es la que interesa al criminólogo, y merece subrayarse que el método la trata con la misma sistemática que a un incendio o a una avería, con la diferencia esencial de que un atacante elige su objetivo y adapta su conducta, algo que el modelo captura de forma limitada.

La degradación expresa cuánto daña la amenaza al activo cuando se materializa, en términos de porcentaje del valor perdido. La probabilidad o frecuencia expresa cuántas veces cabe esperar que ocurra en un periodo. El impacto es el daño resultante sobre el activo, y el riesgo combina ese impacto con la frecuencia estimada.

Una salvaguarda es cualquier medida —técnica, organizativa, física o relativa al personal— que reduce el riesgo, ya sea disminuyendo la frecuencia con que la amenaza se materializa o limitando la degradación que provoca. Esa distinción es más importante de lo que parece: un cortafuegos reduce la frecuencia de la intrusión, una copia de seguridad no evita el cifrado por un programa de secuestro pero recorta drásticamente el daño, y un registro de actividad no impide nada, aunque hace posible investigar y acreditar lo ocurrido.

El árbol de dependencias

La aportación más elegante del método, y la peor comprendida, es el modelo de dependencias entre activos.

La idea de partida es que el valor no reside en las máquinas, sino en la información y en los servicios que la organización presta. Un servidor concreto no vale nada por sí mismo; vale por lo que soporta. MAGERIT formaliza esa intuición estableciendo que los activos dependen unos de otros y que el valor se transmite desde los activos esenciales hacia abajo, hacia los activos que los sustentan. La información del padrón municipal tiene un valor determinado; la base de datos que la almacena hereda ese valor; el servidor que ejecuta la base de datos lo hereda a su vez; la sala donde está el servidor, también.

Las consecuencias prácticas de ese mecanismo son considerables. La primera es que valorar activos técnicos de forma directa constituye un error metodológico frecuente: quien puntúa la confidencialidad de un servidor sin haber valorado antes la información que trata está inventándose un número. La segunda es que el análisis revela concentraciones de riesgo que la intuición no detecta, porque un activo aparentemente menor puede acumular el valor heredado de muchos servicios esenciales. Un directorio de identidades, un sistema de copias o un enlace de comunicaciones suelen ser, en el modelo, los puntos más críticos de toda la organización, y rara vez están en el primer lugar de las preocupaciones cotidianas.

La tercera consecuencia interesa de manera directa al trabajo forense. El árbol de dependencias, bien construido, es también un mapa de propagación del incidente: describe por dónde puede extenderse un compromiso y qué queda afectado cuando cae cada pieza. Un analista que disponga del modelo de dependencias de la organización tiene, antes de empezar a investigar, una hipótesis razonada del alcance del daño.

Valorar sin inventarse los números

La valoración es el punto donde el método se juega su credibilidad, y también donde con más frecuencia se le critica.

MAGERIT valora cada activo en las cinco dimensiones que después recogió el Esquema Nacional de Seguridad: disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad. Un mismo activo puede ser muy valioso en una dimensión e irrelevante en otra. El registro de accesos de un sistema tiene un valor bajo en confidencialidad y un valor altísimo en integridad y en trazabilidad, precisamente porque su función es dar fe de lo ocurrido.

La escala de valoración es cualitativa, con niveles que van de despreciable a muy alto, y con un rasgo que conviene explicar bien porque genera malentendidos: es una escala logarítmica. Cada peldaño representa un salto de magnitud respecto del anterior, de manera que la distancia entre un valor medio y uno alto es mucho mayor que la que sugiere la diferencia de dos números consecutivos. Esa decisión de diseño responde a la naturaleza de los daños que se están midiendo, que se distribuyen en órdenes de magnitud muy dispares.

Para que la valoración no se convierta en una encuesta de opiniones, el método proporciona criterios de valoración: enunciados que describen qué significa cada nivel en términos de perjuicio para la organización, para las personas, para el cumplimiento normativo, para la imagen o para las relaciones institucionales. El analista no elige un número; elige el enunciado que mejor describe la consecuencia y anota el nivel asociado. Ese matiz es el que separa un análisis defendible de una colección de intuiciones, y es lo primero que conviene comprobar al revisar un análisis ajeno: si los criterios de valoración están escritos y se han aplicado de forma coherente en todo el modelo.

Un análisis serio documenta además quién valoró cada activo. Las valoraciones no las hace el técnico, sino el responsable de la información o del servicio, que es quien conoce las consecuencias de su pérdida. Un análisis de riesgos firmado únicamente por el departamento de informática está mal hecho por construcción, y esa objeción es de las más eficaces cuando hay que impugnar un documento de este tipo.

La aritmética del riesgo

Con los activos valorados y las amenazas identificadas, el cálculo es conceptualmente simple.

Para cada par de activo y amenaza se estiman dos magnitudes. La degradación indica qué porcentaje del valor del activo se pierde si la amenaza se materializa, y se estima por dimensión: un incendio degrada la disponibilidad casi por completo y no afecta a la confidencialidad; una filtración degrada la confidencialidad de forma total y deja intacta la disponibilidad. La frecuencia estima cuántas veces al año cabe esperar el suceso, con escalas que van desde lo que ocurre a diario hasta lo que sucede cada varios años.

El impacto resulta de aplicar la degradación al valor del activo. El riesgo resulta de ponderar ese impacto con la frecuencia estimada. Cuando el modelo trabaja con dependencias, el impacto sobre un activo técnico se propaga hacia arriba y se traduce en impacto sobre los servicios y la información que dependen de él, que es lo que finalmente interesa a la organización.

Conviene ser claro sobre la naturaleza de estos números, porque su apariencia cuantitativa engaña. No son mediciones. Son estimaciones ordenadas, expresadas en una escala común para que puedan compararse entre sí y priorizarse. Su utilidad reside en la comparación relativa —qué riesgos son mayores que otros dentro de la misma organización— mucho más que en el valor absoluto de cada uno. Presentar en un informe pericial el resultado de un análisis MAGERIT como si fuera una medición objetiva del riesgo es un error que un perito contrario desmontará sin dificultad.

Las salvaguardas y su madurez

Hasta aquí, el sistema desnudo. La segunda mitad del análisis consiste en incorporar lo que la organización ya hace para protegerse.

El catálogo tipifica las salvaguardas por su función y por su efecto. Unas actúan antes del suceso, reduciendo la probabilidad de que ocurra; otras lo detectan mientras ocurre; otras limitan sus consecuencias; otras permiten recuperarse; y otras, que interesan de manera especial en este ámbito, sirven para investigar y acreditar lo sucedido. Los registros de actividad, la sincronización horaria fiable, las copias de la configuración y los procedimientos de recogida de evidencias pertenecen a esta última categoría, y su presencia o ausencia en un análisis de riesgos dice mucho sobre la madurez real de la organización.

La eficacia de cada salvaguarda no se declara como presente o ausente, sino que se gradúa mediante una escala de madurez de seis niveles heredada de los modelos de capacidad: desde la inexistencia total, pasando por la aplicación improvisada, la repetible, la documentada y la medida, hasta la mejora continua. Una copia de seguridad que se hace cuando alguien se acuerda y una copia verificada, cifrada, con restauración probada periódicamente y con registro de las pruebas son la misma salvaguarda en el papel y dos cosas radicalmente distintas en la realidad. La escala de madurez es el instrumento con el que el método captura esa diferencia.

Ese detalle tiene consecuencias jurídicas evidentes. En un procedimiento donde se discuta la diligencia de una entidad, la distancia entre «teníamos copias de seguridad» y «teníamos copias de seguridad verificadas mensualmente, con registro de las restauraciones de prueba» es exactamente la distancia entre una afirmación y una prueba. El análisis de riesgos, si está bien hecho, documenta cuál de las dos situaciones era la real y desde cuándo.

Del riesgo potencial al riesgo residual

El método distingue varios estados del riesgo, y confundirlos es una de las causas más frecuentes de malas lecturas de estos documentos.

El riesgo potencial es el que existiría si la organización no tuviera ninguna salvaguarda implantada. Es una magnitud teórica, útil para dimensionar la exposición del sistema y para justificar inversiones, y carece de sentido interpretarla como una descripción de la situación real.

El riesgo residual es el que queda tras aplicar las salvaguardas existentes con la madurez que realmente tienen. Es la magnitud que describe la situación actual y la que debería centrar cualquier discusión seria sobre la seguridad de una organización.

Entre ambos suele representarse un tercer estado, el riesgo objetivo, que es el nivel al que la organización aspira a llegar tras ejecutar su plan de seguridad. La diferencia entre el residual y el objetivo es, precisamente, la lista de tareas pendientes, y de ahí sale el plan de seguridad con sus proyectos, sus plazos y sus responsables.

Un análisis de riesgos que presenta solo el riesgo potencial está incompleto y resulta poco informativo. Uno que presenta el residual sin explicar con qué madurez se han evaluado las salvaguardas es sospechoso. Y uno que muestra un riesgo residual uniformemente bajo en toda la organización suele indicar que las salvaguardas se han declarado con optimismo, cosa que se detecta contrastando esas declaraciones con la evidencia técnica: los informes de la herramienta de auditoría de configuración, los registros de las pruebas de restauración, las actas de las revisiones.

PILAR: la herramienta que hace el trabajo

Aplicar MAGERIT a mano sobre una organización de tamaño medio es materialmente inviable. El número de combinaciones entre activos, dimensiones, amenazas y salvaguardas crece muy deprisa, y el cálculo con propagación por el árbol de dependencias resulta imposible de sostener en una hoja de cálculo. De ahí que la metodología y su herramienta vayan siempre juntas.

PILAR es esa herramienta. Nació en el entorno académico y técnico español y se distribuye bajo licencia del Centro Criptológico Nacional, que la pone a disposición de los organismos de la Administración pública. Su desarrollo continúa de forma activa: la familia se actualiza periódicamente, con versiones identificadas por año, entre ellas la 2025.1.2 publicada el 28 de marzo de 2025.

La herramienta se presenta en varias variantes que responden a necesidades distintas. La versión completa está pensada para análisis exhaustivos de sistemas complejos. PILAR Basic simplifica el modelo para entidades pequeñas y para la administración local, donde el esfuerzo de un análisis completo resultaría desproporcionado. La variante reducida, conocida como µPILAR, permite análisis muy rápidos y ligeros. Y existe un conjunto de utilidades adicionales para adaptar los catálogos y los perfiles a necesidades particulares.

Más allá del cálculo del riesgo, las versiones actuales incorporan módulos de cumplimiento que comparan la situación de la organización con marcos normativos concretos, entre ellos el Esquema Nacional de Seguridad y el Reglamento General de Protección de Datos. Esa función explica buena parte de su adopción real: permite obtener, del mismo modelo, el análisis de riesgos y una estimación del grado de cumplimiento normativo.

El CCN publica los manuales de la herramienta dentro de la propia serie CCN-STIC, en las guías dedicadas a PILAR, a PILAR Basic y a la variante reducida. Quien tenga que revisar un análisis ajeno hará bien en consultarlos, porque explican qué significa exactamente cada pantalla y cada informe, y permiten detectar cuándo alguien ha aceptado los valores por omisión sin pensarlos.

Ese último punto merece un aviso. La herramienta incorpora catálogos y perfiles de seguridad predefinidos que aceleran enormemente el trabajo y que, usados sin criterio, producen análisis que se parecen todos entre sí y no describen a ninguna organización en particular. Un análisis de riesgos donde el inventario de activos es genérico, las valoraciones coinciden con las sugeridas y las amenazas son las del catálogo sin ajustar es un documento con muy poco valor probatorio, por impecable que sea su aspecto.

Cómo se hace un análisis que aguante una revisión

El procedimiento, despojado de tecnicismos, tiene una secuencia clara y cada paso deja un rastro documental que puede examinarse después.

Se empieza delimitando el alcance: qué sistemas, qué servicios y qué sedes entran en el análisis y cuáles quedan fuera. Un alcance mal definido invalida todo lo que viene después, y es la primera cosa que conviene mirar al revisar un documento ajeno, porque los sistemas problemáticos tienden a quedar fuera del perímetro con notable frecuencia.

Se identifican después los activos y se construye el árbol de dependencias, tarea que exige hablar con quien opera los sistemas y no solo con quien los administra. Se valoran los activos esenciales conforme a los criterios establecidos, con la participación de los responsables de la información y de los servicios. Se caracterizan las amenazas pertinentes para cada clase de activo, ajustando el catálogo a la realidad de la organización y a su contexto: no amenaza lo mismo una inundación a un centro de proceso de datos en un sótano que a otro en una tercera planta.

Se inventarían y evalúan las salvaguardas existentes con su madurez real, apoyándose en evidencia y no en declaraciones. Se calculan el riesgo potencial y el residual. Se comparan con los criterios de aceptación que la organización haya fijado, y los riesgos que los superen se tratan mediante alguna de las opciones clásicas: reducirlos con nuevas salvaguardas, transferirlos mediante contratos o seguros, evitarlos suprimiendo la actividad que los genera o aceptarlos de forma expresa y motivada.

Ese último paso, la aceptación formal del riesgo residual, es el que más consecuencias jurídicas acarrea y el que más a la ligera se ejecuta. Aceptar un riesgo es una decisión de la dirección de la organización, no del departamento técnico, y debe quedar documentada con la firma de quien tiene competencia para asumirla. Un riesgo aceptado por escrito por el órgano competente y que después se materializa sitúa a la organización en una posición defendible, siempre que la decisión fuera razonable con la información disponible. El mismo riesgo materializado sin decisión previa, o con una decisión adoptada por quien no tenía autoridad para tomarla, deja a la entidad sin argumento.

Todo el proceso culmina en un conjunto de productos documentales que conviene conocer porque son los que se piden en una auditoría o se reclaman en un procedimiento: el modelo de valor con los activos y sus valoraciones, el mapa de riesgos, la evaluación de las salvaguardas, el estado de riesgo, el informe de insuficiencias con lo que falta y el plan de seguridad con los proyectos previstos.

Un supuesto de trabajo: el hospital comarcal y su proveedor de imagen

El modelo se entiende mejor aplicado a un caso. El que sigue está construido con fines docentes y no reproduce ningún expediente concreto, aunque combina situaciones frecuentes.

Un hospital comarcal analiza el riesgo de su sistema de diagnóstico por imagen. Los activos esenciales son claros: el servicio de diagnóstico, del que depende la actividad clínica, y la información de las pruebas, que es información de salud y por tanto de categoría especial en materia de protección de datos. La valoración de esos dos activos la hacen la dirección médica y la responsable de la información, con criterios escritos: la indisponibilidad prolongada del diagnóstico por imagen tiene consecuencias directas sobre la asistencia, y la divulgación de las pruebas afecta a la intimidad de personas identificables.

De ahí hacia abajo se despliega el árbol. La información reside en un archivo de imágenes médicas, que se ejecuta sobre unos servidores, que dependen de un almacenamiento compartido, de una red interna, de un sistema de identidades que autoriza el acceso de los facultativos y de un enlace con el proveedor externo que presta el servicio de informe radiológico a distancia. Cada una de esas piezas hereda el valor de los activos esenciales que sostiene.

El análisis produce entonces un resultado que la intuición no anticipa. El activo con mayor riesgo residual no es el archivo de imágenes, que está bien protegido y respaldado, sino el sistema de identidades, porque de él dependen simultáneamente el diagnóstico por imagen y otros seis servicios del hospital, y porque su compromiso degrada a la vez la confidencialidad, la integridad y la trazabilidad de todos ellos. La segunda posición la ocupa el enlace con el proveedor externo, por una razón distinta: la organización controla su extremo del canal y no controla lo que ocurre al otro lado.

Ese segundo hallazgo abre el capítulo del riesgo de terceros, que es hoy uno de los puntos más débiles de los análisis reales. Cuando una parte del tratamiento se realiza fuera, el riesgo no desaparece, se traslada, y la organización sigue respondiendo de él ante los pacientes y ante la autoridad de control. El método permite modelarlo incorporando el servicio externo como activo con sus propias dependencias y amenazas, y la gestión se articula por vía contractual: obligaciones de seguridad explícitas, derecho de auditoría, notificación de incidentes en plazo y acreditación periódica del cumplimiento. Un análisis de riesgos que ignora los servicios contratados a terceros describe la mitad del sistema.

El valor forense de este ejercicio se aprecia cuando algo falla. Si meses después se produce un acceso no autorizado a través de una credencial del proveedor, el análisis previo demuestra que la organización había identificado esa vía, había estimado su impacto y había decidido de forma expresa qué medidas exigía. Y si el análisis no la había identificado, ese silencio también es información relevante, porque señala una carencia de método en un punto que cualquier profesional razonable habría examinado.

Los errores que se repiten

Quien revisa análisis de riesgos con cierta frecuencia acaba encontrándose siempre los mismos defectos, y merece la pena enumerarlos porque son los puntos donde conviene mirar primero.

El inventario de activos irreal encabeza la lista. Sistemas que ya no existen, sistemas nuevos que no aparecen, servicios contratados a terceros que nadie ha incorporado al modelo y, sobre todo, la ausencia de los activos que la organización ha ido acumulando fuera del control del departamento de informática. Un análisis de riesgos que no incluye lo que realmente sostiene la actividad describe una organización imaginaria.

La valoración desconectada de los criterios es el segundo defecto habitual. Cuando todos los activos resultan de valor alto, la priorización desaparece y el análisis deja de servir para lo único que sirve realmente, que es decidir por dónde empezar.

La declaración optimista de salvaguardas es el tercero, y el más fácil de detectar con evidencia técnica. Basta contrastar la madurez declarada con los informes de auditoría de configuración, con los registros de las pruebas de recuperación o con la formación efectivamente impartida.

El cuarto es el envejecimiento. Un análisis de riesgos es un documento vivo que debe revisarse cuando cambia el sistema, cuando cambia el contexto de amenazas o cuando ocurre un incidente relevante. Encontrar un análisis firmado hace cuatro años, sin revisiones, en una organización que ha migrado la mitad de sus servicios a la nube durante ese periodo, informa mucho más sobre la entidad que su contenido.

Y el quinto es el análisis heredado, aquel que se copia de otra organización o de un ejercicio anterior y se ajusta ligeramente. Se reconoce porque las dependencias no encajan con la arquitectura real y porque los riesgos identificados no guardan relación con los incidentes que la organización ha sufrido de verdad.

El análisis de riesgos como prueba

Llegamos al punto que más interesa a los lectores de esta revista: qué papel juega este documento en un procedimiento.

El análisis de riesgos es, en primer lugar, la prueba principal de la diligencia de una organización en materia de seguridad. El artículo 32 del Reglamento General de Protección de Datos exige medidas técnicas y organizativas apropiadas al riesgo, expresión que carece de sentido sin una valoración previa de ese riesgo. El Esquema Nacional de Seguridad lo exige de forma expresa para los sistemas de su ámbito. Una entidad que no puede exhibir un análisis actualizado no tiene manera de acreditar que sus medidas eran proporcionadas, porque no consta contra qué se dimensionaron.

En segundo lugar, y aquí está el filo peligroso, el análisis es también prueba de conocimiento. Un riesgo identificado, valorado como alto y no tratado, o tratado con un plan que nunca se ejecutó, documenta que la organización sabía. Ese conocimiento previo, acreditado por su propio documento, agrava la valoración de la conducta cuando el riesgo se materializa. Conviene decirlo con claridad porque explica una conducta que se observa con cierta frecuencia: la tentación de no escribir el riesgo para no dejar constancia de que se conocía. Esa estrategia es pésima en todos los sentidos, porque la ausencia del análisis es en sí misma un incumplimiento y porque la organización sigue expuesta.

En tercer lugar, el documento sirve para reconstruir el contexto en el que se tomaron las decisiones. Un tribunal juzga conductas situadas en el tiempo, y un análisis de riesgos fechado permite valorar si la decisión fue razonable con la información disponible entonces, en lugar de con la que se tiene ahora, cuando el daño ya ha ocurrido y todo parece previsible. Ese sesgo retrospectivo es uno de los principales enemigos de una valoración justa, y un análisis de riesgos bien fechado y firmado es la mejor defensa frente a él.

Para el perito hay una consecuencia práctica. Al examinar un análisis de riesgos ajeno conviene verificar, por este orden, el alcance declarado, la fecha y sus revisiones, quién firmó cada valoración, la coherencia entre las salvaguardas declaradas y la evidencia técnica disponible, y el rastro de la aceptación formal de los riesgos residuales. Esos cinco puntos concentran la mayor parte de las debilidades de estos documentos.

Qué comprobar	Señal de solidez	Señal de alarma
Antes de entrar en el contenido
Alcance declarado	Se dice con precisión qué sistemas y sedes entran y cuáles quedan fuera, con su motivo	El sistema implicado en el incidente quedaba fuera del perímetro analizado
Fecha y revisiones	Revisado tras cada cambio relevante del sistema o del contexto de amenazas	Firmado hace años y sin revisiones, pese a migraciones o incidentes de por medio
El modelo del sistema
Inventario de activos	Refleja los sistemas reales, incluidos los servicios contratados a terceros	Inventario genérico, con sistemas que ya no existen y ausencias notorias
Árbol de dependencias	Coherente con la arquitectura real y con quien opera cada pieza	Estructura tomada del catálogo sin adaptar a la organización
Valoración de los activos	Criterios de valoración escritos y aplicados de forma coherente en todo el modelo	Todos los activos con valor alto, lo que anula cualquier priorización
Autoría de la valoración	Firmada por los responsables de la información y de los servicios	Firmada únicamente por el departamento de informática
Salvaguardas, riesgo y decisión
Madurez de las salvaguardas	Apoyada en informes de auditoría, registros y pruebas documentadas	Declarada en una entrevista, sin evidencia que la respalde
Riesgo presentado	Potencial y residual, con explicación del cálculo y de las hipótesis	Solo el potencial, o un residual uniformemente bajo en toda la organización
Aceptación del riesgo residual	Firmada y fechada por el órgano con competencia para asumirla	Ausente, o firmada por quien no tenía autoridad para decidirlo
Plan de seguridad	Proyectos con responsable, plazo y seguimiento acreditado	Aprobado y sin ejecutar, sin justificación de la demora

Dos documentos que se confunden constantemente

Conviene deshacer un equívoco muy extendido, porque genera respuestas erróneas en inspecciones y en juicios. El análisis de riesgos de un sistema de información y la evaluación de impacto relativa a la protección de datos son documentos distintos, con finalidades distintas y bases jurídicas distintas.

El análisis de riesgos que produce MAGERIT mira hacia la organización: identifica lo que la entidad puede perder si sus sistemas fallan o son atacados, y dimensiona las medidas de seguridad en consecuencia. Su lógica es la de la continuidad y la protección del patrimonio informacional propio.

La evaluación de impacto del artículo 35 del Reglamento General de Protección de Datos mira hacia fuera: analiza el riesgo que un tratamiento supone para los derechos y libertades de las personas afectadas. El sujeto del daño no es la organización, sino el ciudadano cuyos datos se tratan. Es obligatoria cuando el tratamiento entraña un riesgo alto, y su ausencia constituye una infracción autónoma.

Ambos documentos comparten insumos —el inventario de activos, el mapa de dependencias, la evaluación de las medidas de seguridad— y por eso las herramientas actuales, PILAR entre ellas, incorporan módulos que reutilizan el modelo para responder a las dos preguntas. Compartir insumos no los convierte en el mismo documento. Una entidad que responde a un requerimiento de la autoridad de control aportando su análisis de riesgos del Esquema Nacional de Seguridad como si fuera una evaluación de impacto está entregando algo que no se le ha pedido.

Para el perito, la distinción tiene un rendimiento inmediato. Cuando se examina el expediente de una entidad tras una brecha de datos personales, conviene comprobar por separado si existía el análisis de riesgos del sistema, si existía la evaluación de impacto del tratamiento afectado y si ambos documentos son coherentes entre sí. Las contradicciones entre los dos —un riesgo calificado de bajo en uno y de alto en el otro, sobre el mismo sistema y en fechas próximas— son un hallazgo relevante que suele apuntar a que uno de los dos se elaboró como mero trámite.

Qué preguntar cuando el análisis llega al despacho

Buena parte de los lectores de esta revista no elaborará nunca un análisis de riesgos, y en cambio muchos tendrán que leer uno, valorarlo o interrogar a quien lo firmó. Estas son las preguntas que suelen resultar más productivas, ordenadas por rendimiento.

Sobre el alcance: ¿qué sistemas quedaron fuera y por qué? La respuesta revela con frecuencia que el sistema implicado en el incidente no formaba parte del perímetro analizado, lo que a su vez plantea la cuestión de si esa exclusión estaba justificada.

Sobre la autoría: ¿quién valoró la información y los servicios? Si la respuesta es «el departamento de informática», el documento tiene un defecto de origen, porque quien conoce las consecuencias de perder la información es el responsable de esa información.

Sobre la evidencia: ¿en qué se apoyó la evaluación de madurez de cada salvaguarda? Un análisis serio se apoya en informes de auditoría, registros y pruebas documentadas; uno flojo, en una entrevista.

Sobre la vigencia: ¿cuándo se revisó por última vez y qué cambios del sistema motivaron esa revisión? Un documento sin revisiones en una organización que ha cambiado su arquitectura habla por sí solo.

Sobre las decisiones: ¿quién aceptó formalmente los riesgos residuales y con qué fecha? La ausencia de esa aceptación deja el plan de seguridad huérfano de decisión, y la presencia de una aceptación firmada por quien no tenía competencia para asumirla es igualmente problemática.

Y sobre la ejecución: ¿qué proyectos del plan de seguridad se completaron y cuáles no? Un plan aprobado y no ejecutado es, en un procedimiento, una prueba escrita de que la organización conocía la carencia y no la corrigió, lo que exige a su vez examinar si hubo una razón atendible para esa demora.

MAGERIT frente a otras metodologías

Situar MAGERIT en el panorama internacional ayuda a valorar sus decisiones de diseño y a responder con solvencia cuando alguien pregunta por qué se usa esta y no otra.

La norma ISO/IEC 27005 ofrece directrices para la gestión de los riesgos de seguridad de la información dentro de un sistema de gestión conforme a la ISO/IEC 27001, sin prescribir un método concreto de cálculo. MAGERIT encaja dentro de ese marco y aporta lo que la norma deliberadamente no da: un procedimiento detallado y un catálogo de elementos listo para usar. La familia ISO 31000 opera un escalón más arriba, en la gestión del riesgo de cualquier naturaleza dentro de la organización.

En el ámbito estadounidense, la publicación NIST SP 800-30 desarrolla la conducción de evaluaciones de riesgo dentro del marco de gestión federal. Francia mantiene EBIOS Risk Manager, con un enfoque muy orientado a escenarios de ataque y a la perspectiva del adversario. Alemania integra su análisis de riesgos en el corpus IT-Grundschutz. Y en el terreno de la cuantificación económica del riesgo se ha consolidado el modelo FAIR, que trabaja con distribuciones de probabilidad y estimaciones monetarias y que responde a una filosofía distinta de la de MAGERIT.

La literatura académica ha comparado estos métodos con criterios sistemáticos. Shameli-Sendi, Aghababaei-Barzegar y Cheriet (2016) propusieron una taxonomía de las metodologías de evaluación de riesgos que permite clasificarlas según su perspectiva y su nivel de detalle. Wangen, Hallstensen y Snekkenes (2018) desarrollaron un marco para estimar la completitud de los métodos y compararon un conjunto amplio de ellos, encontrando diferencias notables en la cobertura de las fases del proceso. Y en el caso concreto de la metodología española, Vicente, Mateos y Jiménez-Martín (2014) propusieron una extensión difusa de MAGERIT precisamente para tratar con mayor finura la imprecisión inherente a las valoraciones cualitativas.

De esa comparación emerge un balance razonable. MAGERIT destaca por la calidad de su catálogo de elementos, por la coherencia interna de su modelo de dependencias y por su encaje directo con el marco normativo español. Queda por detrás en el tratamiento explícito del comportamiento del adversario, terreno donde EBIOS Risk Manager ha avanzado más, y en la cuantificación económica, donde los enfoques de tipo FAIR ofrecen resultados más útiles para una conversación con la dirección financiera.

Lo que la metodología no resuelve

Un monográfico honesto tiene que dedicar espacio a los límites, y este los tiene.

El primero es la subjetividad de las estimaciones. Por muchos criterios que se documenten, la degradación y la frecuencia las estima una persona, y personas distintas producen resultados distintos sobre el mismo sistema. El método mitiga el problema con catálogos y criterios comunes, sin llegar a eliminarlo. Interpretar los resultados como si fueran mediciones es un error, y ya se ha señalado antes.

El segundo es el esfuerzo. Un análisis riguroso sobre una organización mediana consume semanas de trabajo de personas que conocen bien los sistemas y que suelen ser las mismas que los operan. Esa competencia por el tiempo explica muchos análisis mediocres, y la aparición de variantes ligeras de la herramienta es un reconocimiento explícito del problema.

El tercero es el envejecimiento del propio método. La versión vigente se publicó en 2012, y desde entonces han cambiado de forma sustancial las arquitecturas de nube, la dependencia de proveedores de servicios gestionados, la cadena de suministro del software y, más recientemente, la incorporación de sistemas de inteligencia artificial a los procesos de las organizaciones. Nada de eso está bien representado en un catálogo de activos y amenazas de hace más de una década, y la práctica ha ido resolviéndolo mediante adaptaciones que dependen del criterio de cada analista.

El cuarto es la dificultad de modelar al adversario. El método trata los ataques deliberados con la misma mecánica que los sucesos accidentales, cuando su naturaleza es distinta: un atacante observa, aprende y elige el momento y el objetivo. Aproximaciones basadas en escenarios de ataque y en el estudio de tácticas y técnicas del adversario complementan bien este punto, y es la línea por la que avanzan las metodologías más recientes.

Reconocer estos límites no resta valor al método. Un análisis de riesgos imperfecto pero honesto, revisado y firmado por quien corresponde, sigue siendo infinitamente más útil —y más defendible— que la ausencia de cualquier análisis, que es la situación real de muchísimas organizaciones.

Saber lo que se arriesga

La utilidad última de MAGERIT y de PILAR no está en el número que producen, sino en la conversación que obligan a mantener. Determinar qué información y qué servicios importan de verdad, quién responde de ellos, de qué piezas dependen, qué puede salirles mal y qué se está haciendo al respecto es un ejercicio que ninguna organización hace de forma espontánea. La metodología proporciona el guion para esa conversación y, sobre todo, deja constancia escrita y fechada de lo que se dijo y de quién lo decidió.

Para el profesional de la criminología y de las ciencias forenses, ese documento es una fuente de primer orden. Describe la arquitectura del sistema, señala sus puntos débiles conocidos, revela qué se sabía y desde cuándo, y muestra qué decidió la organización hacer con ese conocimiento. Leerlo bien exige entender su vocabulario y sus convenciones, que es lo que hemos intentado ofrecer en estas páginas.

Con esta entrega, la serie ha recorrido el catálogo de guías del CCN, la selección comentada de las más útiles en investigación, un caso práctico de preparación forense, la guía de ciberinteligencia, la de gestión de ciberincidentes, el ecosistema de herramientas del organismo, la comparación con los estándares internacionales de bastionado y, ahora, la metodología de riesgos. Los siguientes temas están ya sobre la mesa: el análisis forense del código dañino, con la guía CCN-STIC-834 como referencia, y el traslado de la preparación forense al entorno de Windows y Active Directory, que es donde trabaja la mayoría de las organizaciones.

Risk Before the Incident: MAGERIT and PILAR, the Methodology the Spanish Security Framework Takes for Granted

Leer en español

Every security audit asks for a risk assessment, every expert report eventually stumbles over one, and very few legal professionals know what is actually inside that document. A monograph on the Spanish risk analysis and management methodology and on the tool that implements it.

The question nobody asked in time

When a serious incident reaches a court or a regulatory file, the conversation soon turns to a question that sounds like common sense: did the organisation know this could happen? Much of the blame depends on the answer. An entity that had identified the threat, assessed it and made a reasoned decision about it stands in a very different position from one that had never considered the matter at all.

The document where that answer should be recorded is called a risk assessment. In Spain, when the subject is public sector information systems, that document is almost always produced with one particular methodology, MAGERIT, and one particular tool, PILAR. Both are mentioned constantly in audits, procurement specifications and expert reports, and both remain opaque to most legal and criminology professionals who have to interpret their results.

This article closes the circle we opened in the previous instalment of this series. There we compared two hardening catalogues —the CIS Benchmarks and the CCN-STIC guides— and noted that neither resolves the risk layer. That layer is our subject now, so that anyone reading a risk assessment knows what they are reading, where the defects usually lie, and what can and cannot be concluded from it.

Where MAGERIT comes from

MAGERIT is the Spanish acronym for Methodology for Information Systems Risk Analysis and Management. It was produced by the Higher Council for Electronic Administration, a body of the Spanish central government, and its first version dates from 1997, at the height of the roll-out of the administration’s electronic services. The second version arrived in 2006 and the third, which remains in force, was published in October 2012 under the Ministry of Finance and Public Administrations.

That date deserves an honest comment at the outset. Version 3 is more than a decade old and remains the reference, with no version 4 published. Effective updating has come by other routes: through the evolution of the PILAR tool, maintained with annual releases; through the CCN-STIC guides that accompany it; and through the National Security Framework itself, whose 2022 text requires a risk assessment with a defined content. Anyone working with MAGERIT today must keep that time gap in mind, particularly when modelling technologies whose weight in 2012 was very different from today’s.

The methodology was published in three books that are worth distinguishing, because they are often cited loosely. The first, the Method, contains the procedure: which steps to take, in what order and with what documentary outputs. The second, the Catalogue of Elements, is a typified inventory of asset classes, valuation dimensions, criteria, threats and safeguards, designed so that two different analysts use the same vocabulary. The third, the Guide to Techniques, gathers supporting analytical tools, from table-based analysis to attack trees.

The design follows a philosophy worth understanding before criticising it. MAGERIT is an essentially qualitative methodology, built to produce comparable and auditable results in organisations that hold no actuarial data on incidents. That approach costs precision and gains applicability, and it explains many design decisions that an economist or an actuary would find odd.

The vocabulary: assets, threats, safeguards, impact and risk

The whole edifice rests on a small set of concepts worth fixing precisely, because the colloquial use of the same words generates enormous confusion in reports.

An asset is any element of the information system that has value for the organisation. The catalogue classifies them: information and services as essential assets, followed by data, cryptographic keys, applications, physical equipment, communications, information media, auxiliary equipment, facilities and people. That classification is no taxonomic whim: each class carries plausible threats and pertinent safeguards in the catalogue, so correctly classifying an asset determines much of the subsequent analysis.

A threat is an event that may befall an asset and cause harm. The catalogue groups them into four families that work well when explaining the model to a court: natural disasters, industrial events, unintentional errors and failures, and deliberate attacks. That last family is the one that interests the criminologist, and it is worth stressing that the method treats it with the same machinery as a fire or a breakdown, with the essential difference that an attacker chooses a target and adapts, something the model captures only partially.

Degradation expresses how much the threat damages the asset when it materialises, as a percentage of value lost. Probability or frequency expresses how often it may be expected over a period. Impact is the resulting harm to the asset, and risk combines that impact with the estimated frequency.

A safeguard is any measure —technical, organisational, physical or concerning personnel— that reduces risk, either by lowering the frequency with which the threat materialises or by limiting the degradation it causes. That distinction matters more than it seems: a firewall reduces the frequency of intrusion, a backup does not prevent encryption by ransomware but sharply cuts the harm, and an activity log prevents nothing, although it makes it possible to investigate and to establish what happened.

The dependency tree

The method’s most elegant contribution, and the least understood, is its model of dependencies between assets.

The starting idea is that value does not reside in machines but in the information and the services the organisation delivers. A particular server is worth nothing in itself; it is worth what it supports. MAGERIT formalises that intuition by establishing that assets depend on one another and that value flows down from essential assets towards the assets that sustain them. The information in a municipal register has a given value; the database that stores it inherits that value; the server running the database inherits it in turn; so does the room where the server sits.

The practical consequences are considerable. The first is that valuing technical assets directly is a common methodological error: anyone scoring the confidentiality of a server without first valuing the information it processes is inventing a number. The second is that the analysis reveals concentrations of risk that intuition misses, because an apparently minor asset may accumulate value inherited from many essential services. An identity directory, a backup system or a communications link are usually, in the model, the most critical points in the whole organisation, and they are rarely at the top of anyone’s daily worries.

The third consequence bears directly on forensic work. A well-built dependency tree is also a map of incident propagation: it describes how a compromise may spread and what is affected when each piece falls. An analyst holding the organisation’s dependency model has, before starting the investigation, a reasoned hypothesis about the extent of the harm.

Valuing without inventing the numbers

Valuation is where the method stakes its credibility, and also where it is most often criticised.

MAGERIT values each asset across the five dimensions later adopted by the National Security Framework: availability, integrity, confidentiality, authenticity and traceability. The same asset may be highly valuable in one dimension and irrelevant in another. A system’s access log has low value in confidentiality and very high value in integrity and traceability, precisely because its function is to attest to what happened.

The valuation scale is qualitative, running from negligible to very high, with a feature worth explaining because it causes misunderstandings: it is a logarithmic scale. Each step represents a jump in magnitude over the previous one, so the distance between a medium and a high value is far greater than the difference between two consecutive numbers suggests. That design decision reflects the nature of the harms being measured, which spread across widely differing orders of magnitude.

To keep valuation from becoming an opinion survey, the method supplies valuation criteria: statements describing what each level means in terms of harm to the organisation, to individuals, to regulatory compliance, to reputation or to institutional relations. The analyst does not pick a number; they pick the statement that best describes the consequence and record the associated level. That nuance separates a defensible analysis from a collection of hunches, and it is the first thing to check when reviewing somebody else’s work: whether the valuation criteria are written down and have been applied consistently throughout the model.

A serious analysis also records who valued each asset. Valuations are not made by the technician but by the owner of the information or the service, who knows the consequences of its loss. A risk assessment signed solely by the IT department is flawed by construction, and that objection is among the most effective when such a document has to be challenged.

The arithmetic of risk

With assets valued and threats identified, the calculation is conceptually simple.

For each asset-threat pair, two magnitudes are estimated. Degradation indicates what percentage of the asset’s value is lost if the threat materialises, estimated per dimension: a fire degrades availability almost entirely and does not affect confidentiality; a leak degrades confidentiality completely and leaves availability intact. Frequency estimates how many times a year the event may be expected, on scales ranging from daily occurrences to events separated by several years.

Impact results from applying degradation to the asset’s value. Risk results from weighting that impact by the estimated frequency. When the model works with dependencies, impact on a technical asset propagates upwards and translates into impact on the services and information that depend on it, which is what ultimately concerns the organisation.

It is worth being clear about the nature of these numbers, because their quantitative appearance is deceptive. They are not measurements. They are ordered estimates, expressed on a common scale so that they can be compared and prioritised. Their usefulness lies in relative comparison —which risks are greater than others within the same organisation— far more than in the absolute value of any of them. Presenting the output of a MAGERIT analysis in an expert report as if it were an objective measurement of risk is an error that an opposing expert will dismantle without difficulty.

Safeguards and their maturity

So far, the bare system. The second half of the analysis consists of incorporating what the organisation already does to protect itself.

The catalogue classifies safeguards by function and by effect. Some act before the event, reducing the probability of occurrence; others detect it while it happens; others limit its consequences; others enable recovery; and others, of particular interest here, serve to investigate and establish what occurred. Activity logs, reliable time synchronisation, configuration backups and evidence collection procedures belong to that last category, and their presence or absence in a risk assessment says a great deal about the organisation’s real maturity.

The effectiveness of each safeguard is not declared as present or absent but graded on a six-level maturity scale inherited from capability models: from total absence, through improvised application, repeatable practice, documented practice and measured practice, to continuous improvement. A backup made whenever somebody remembers, and a verified, encrypted backup with periodically tested restoration and a record of those tests, are the same safeguard on paper and two radically different things in reality. The maturity scale is the instrument with which the method captures that difference.

That detail has obvious legal consequences. In proceedings where an entity’s diligence is at issue, the distance between «we had backups» and «we had backups verified monthly, with records of test restorations» is precisely the distance between an assertion and evidence. A well-made risk assessment documents which of the two situations was real, and since when.

From potential to residual risk

The method distinguishes several states of risk, and confusing them is one of the most frequent causes of misreadings of these documents.

Potential risk is what would exist if the organisation had no safeguards in place. It is a theoretical magnitude, useful for sizing the system’s exposure and for justifying investment, and it makes no sense to read it as a description of the real situation.

Residual risk is what remains after applying existing safeguards at the maturity they actually have. It is the magnitude that describes the current situation and the one that should anchor any serious discussion about an organisation’s security.

Between the two, a third state is usually represented: target risk, the level the organisation aims to reach after executing its security plan. The gap between residual and target is precisely the list of pending work, and from it comes the security plan with its projects, deadlines and owners.

A risk assessment presenting only potential risk is incomplete and largely uninformative. One presenting residual risk without explaining the maturity at which safeguards were assessed is suspect. And one showing uniformly low residual risk across the whole organisation usually indicates that safeguards were declared optimistically, something detected by contrasting those declarations with technical evidence: configuration audit reports, restoration test records, review minutes.

PILAR: the tool that does the work

Applying MAGERIT by hand to a medium-sized organisation is materially unfeasible. The number of combinations of assets, dimensions, threats and safeguards grows very quickly, and calculation with propagation through the dependency tree becomes impossible to sustain in a spreadsheet. Hence methodology and tool always travel together.

PILAR is that tool. It grew out of the Spanish academic and technical environment and is distributed under licence from the National Cryptologic Centre, which makes it available to public administration bodies. Development continues actively: the family is updated periodically, with versions identified by year, among them 2025.1.2 released on 28 March 2025.

The tool comes in several variants answering different needs. The full version is intended for exhaustive analyses of complex systems. PILAR Basic simplifies the model for small entities and local government, where a full analysis would be disproportionate. The reduced variant, known as µPILAR, allows very fast and light analyses. And a set of additional utilities exists for adapting catalogues and profiles to particular needs.

Beyond risk calculation, current versions include compliance modules that compare the organisation’s situation against specific regulatory frameworks, among them the National Security Framework and the General Data Protection Regulation. That function explains much of its real adoption: from the same model it yields both the risk assessment and an estimate of regulatory compliance.

The CCN publishes the tool’s manuals within the CCN-STIC series itself, in the guides devoted to PILAR, to PILAR Basic and to the reduced variant. Anyone reviewing somebody else’s analysis would do well to consult them, because they explain exactly what each screen and each report mean, and they make it possible to detect when someone has accepted the default values without thinking about them.

That last point deserves a warning. The tool includes predefined catalogues and security profiles that greatly accelerate the work and that, used uncritically, produce analyses that all look alike and describe no organisation in particular. A risk assessment whose asset inventory is generic, whose valuations match the suggested ones and whose threats are the catalogue’s without adjustment is a document of very little evidentiary value, however impeccable its appearance.

How to produce an analysis that survives review

Stripped of jargon, the procedure has a clear sequence, and each step leaves a documentary trail that can be examined afterwards.

It begins by delimiting the scope: which systems, services and sites are included in the analysis and which are left out. A poorly defined scope invalidates everything that follows, and it is the first thing to look at when reviewing somebody else’s document, because problematic systems tend to fall outside the perimeter with notable frequency.

Assets are then identified and the dependency tree is built, a task that requires talking to those who operate the systems and not only to those who administer them. Essential assets are valued according to the established criteria, with the involvement of the owners of the information and the services. Threats pertinent to each asset class are characterised, adjusting the catalogue to the organisation’s reality and context: a flood does not threaten a basement data centre and a third-floor one in the same way.

Existing safeguards are inventoried and assessed at their real maturity, supported by evidence rather than declarations. Potential and residual risk are calculated. They are compared with the acceptance criteria the organisation has set, and risks exceeding them are treated through one of the classic options: reducing them with new safeguards, transferring them through contracts or insurance, avoiding them by discontinuing the activity that generates them, or accepting them expressly and with reasons.

That last step, the formal acceptance of residual risk, carries the greatest legal consequences and is the one most casually executed. Accepting a risk is a decision for the organisation’s management, not for the technical department, and it must be documented and signed by whoever has authority to assume it. A risk accepted in writing by the competent body and later materialising leaves the organisation in a defensible position, provided the decision was reasonable given the information available. The same risk materialising without a prior decision, or with one taken by somebody lacking authority, leaves the entity without an argument.

The whole process culminates in a set of documentary products worth knowing, because these are what an audit requests or proceedings demand: the value model with assets and their valuations, the risk map, the safeguard assessment, the risk status, the deficiency report setting out what is missing, and the security plan with its planned projects.

A worked scenario: the district hospital and its imaging provider

The model is better understood when applied. What follows is built for teaching purposes and reproduces no specific file, although it combines frequent situations.

A district hospital analyses the risk of its diagnostic imaging system. The essential assets are clear: the diagnostic service, on which clinical activity depends, and the examination data, which is health information and therefore a special category of personal data. Those two assets are valued by the medical directorate and the information owner, against written criteria: prolonged unavailability of diagnostic imaging has direct consequences for patient care, and disclosure of examinations affects the privacy of identifiable individuals.

From there the tree unfolds. The information resides in a medical image archive running on servers that depend on shared storage, on an internal network, on an identity system authorising clinicians’ access, and on a link with the external provider delivering remote radiology reporting. Each of those pieces inherits the value of the essential assets it sustains.

The analysis then produces a result intuition does not anticipate. The asset with the highest residual risk is not the image archive, which is well protected and backed up, but the identity system, because both diagnostic imaging and six other hospital services depend on it simultaneously, and because its compromise degrades the confidentiality, integrity and traceability of all of them at once. Second place goes to the link with the external provider, for a different reason: the organisation controls its own end of the channel and does not control what happens at the other.

That second finding opens the chapter of third-party risk, today one of the weakest points of real analyses. When part of the processing takes place elsewhere, the risk does not disappear, it moves, and the organisation remains answerable for it to patients and to the supervisory authority. The method allows it to be modelled by incorporating the external service as an asset with its own dependencies and threats, and management runs through contract: explicit security obligations, audit rights, incident notification within deadlines and periodic evidence of compliance. A risk assessment that ignores contracted services describes half the system.

The forensic value of this exercise becomes apparent when something fails. If months later an unauthorised access occurs through a provider credential, the prior analysis shows that the organisation had identified that route, estimated its impact and expressly decided which measures it required. And if the analysis had not identified it, that silence is relevant information too, because it points to a methodological gap at a point any reasonable professional would have examined.

The recurring mistakes

Anyone who reviews risk assessments regularly ends up finding the same defects, and they are worth listing because they mark where to look first.

An unrealistic asset inventory heads the list. Systems that no longer exist, new systems that do not appear, services contracted out that nobody incorporated into the model and, above all, the absence of assets the organisation has accumulated outside the control of its IT department. A risk assessment omitting what actually sustains the activity describes an imaginary organisation.

Valuation disconnected from criteria is the second common defect. When every asset turns out to be of high value, prioritisation disappears and the analysis stops serving the only purpose it really serves, which is deciding where to start.

Optimistic declaration of safeguards is the third, and the easiest to detect with technical evidence. It suffices to contrast declared maturity against configuration audit reports, recovery test records or training actually delivered.

The fourth is ageing. A risk assessment is a living document that must be reviewed when the system changes, when the threat context changes or when a significant incident occurs. Finding an assessment signed four years ago, without revisions, in an organisation that has migrated half its services to the cloud in that time, says far more about the entity than its contents do.

The fifth is the inherited analysis, copied from another organisation or from a previous exercise and lightly adjusted. It is recognisable because the dependencies do not match the real architecture and because the identified risks bear no relation to the incidents the organisation has actually suffered.

The risk assessment as evidence

We reach the point of greatest interest to this journal’s readers: the role this document plays in proceedings.

A risk assessment is, first of all, the principal evidence of an organisation’s diligence in security matters. Article 32 of the General Data Protection Regulation requires technical and organisational measures appropriate to the risk, a phrase that is meaningless without a prior assessment of that risk. The National Security Framework requires it expressly for systems within its scope. An entity unable to produce an up-to-date assessment has no way of establishing that its measures were proportionate, because there is no record of what they were sized against.

Second, and here lies the dangerous edge, the assessment is also evidence of knowledge. A risk identified, rated high and left untreated, or treated with a plan that was never executed, documents that the organisation knew. That prior knowledge, established by its own document, aggravates the assessment of its conduct when the risk materialises. This should be said plainly, because it explains a behaviour observed with some frequency: the temptation not to write the risk down so as not to leave a record of knowing about it. That strategy is dreadful in every respect, because the absence of the assessment is itself a breach and because the organisation remains exposed.

Third, the document allows the context of the decisions to be reconstructed. A court judges conduct situated in time, and a dated risk assessment makes it possible to weigh whether a decision was reasonable given the information available then, rather than the information available now, when the harm has occurred and everything looks foreseeable. That hindsight bias is one of the main enemies of a fair assessment, and a properly dated and signed risk assessment is the best defence against it.

For the expert witness there is a practical consequence. When examining somebody else’s risk assessment, it pays to verify, in this order, the declared scope, the date and its revisions, who signed each valuation, the consistency between declared safeguards and available technical evidence, and the trail of formal acceptance of residual risks. Those five points concentrate most of the weaknesses of these documents.

What to check	Sign of soundness	Warning sign
Before looking at the content
Declared scope	States precisely which systems and sites are included and which are not, and why	The system involved in the incident fell outside the analysed perimeter
Date and revisions	Reviewed after every significant change to the system or the threat context	Signed years ago with no revisions, despite migrations or incidents in between
The system model
Asset inventory	Reflects the real systems, including services contracted out to third parties	Generic inventory, with systems that no longer exist and conspicuous omissions
Dependency tree	Consistent with the real architecture and with those who operate each piece	Structure lifted from the catalogue without adapting it to the organisation
Asset valuation	Written valuation criteria applied consistently across the whole model	Every asset rated high, which destroys any prioritisation
Authorship of the valuation	Signed by the owners of the information and of the services	Signed by the IT department alone
Safeguards, risk and decision
Safeguard maturity	Supported by audit reports, records and documented tests	Declared in an interview, with no supporting evidence
Risk presented	Potential and residual, with the calculation and assumptions explained	Potential only, or a uniformly low residual risk across the organisation
Acceptance of residual risk	Signed and dated by the body competent to assume it	Absent, or signed by somebody without authority to decide
Security plan	Projects with an owner, a deadline and evidenced follow-up	Approved and never executed, with no justification for the delay

Two documents that are constantly confused

A widespread misunderstanding is worth clearing up, because it produces wrong answers in inspections and in court. The risk assessment of an information system and the data protection impact assessment are different documents, with different purposes and different legal bases.

The risk assessment produced by MAGERIT looks inward: it identifies what the entity may lose if its systems fail or are attacked, and sizes security measures accordingly. Its logic is one of continuity and protection of the organisation’s own information assets.

The impact assessment of Article 35 of the General Data Protection Regulation looks outward: it analyses the risk that a processing operation poses to the rights and freedoms of the individuals concerned. The subject of the harm is not the organisation but the citizen whose data are processed. It is mandatory where processing entails a high risk, and its absence constitutes an infringement in itself.

Both documents share inputs —the asset inventory, the dependency map, the assessment of security measures— which is why current tools, PILAR among them, include modules that reuse the model to answer both questions. Sharing inputs does not make them the same document. An entity responding to a supervisory authority’s request by producing its National Security Framework risk assessment as though it were an impact assessment is delivering something that was not asked for.

For the expert witness, the distinction pays off immediately. When examining an entity’s file after a personal data breach, it is worth checking separately whether the system risk assessment existed, whether the impact assessment for the affected processing existed, and whether the two documents are consistent with each other. Contradictions between them —a risk rated low in one and high in the other, for the same system and at close dates— are a relevant finding that usually indicates that one of the two was produced as a formality.

What to ask when the assessment reaches the office

Many of this journal’s readers will never produce a risk assessment, and many will nonetheless have to read one, weigh it or question whoever signed it. These are the questions that tend to be most productive, ordered by yield.

On scope: which systems were left out, and why? The answer frequently reveals that the system involved in the incident was not part of the analysed perimeter, which in turn raises the question of whether that exclusion was justified.

On authorship: who valued the information and the services? If the answer is «the IT department», the document has a defect of origin, because the person who knows the consequences of losing the information is its owner.

On evidence: what supported the maturity assessment of each safeguard? A serious analysis rests on audit reports, records and documented tests; a weak one, on an interview.

On currency: when was it last reviewed, and which system changes prompted that review? A document without revisions in an organisation that has changed its architecture speaks for itself.

On decisions: who formally accepted the residual risks, and on what date? The absence of that acceptance leaves the security plan orphaned of a decision, and an acceptance signed by somebody without authority to assume it is equally problematic.

And on execution: which security plan projects were completed and which were not? An approved and unexecuted plan is, in proceedings, written evidence that the organisation knew of the shortcoming and did not correct it, which in turn calls for examining whether there was a defensible reason for the delay.

MAGERIT among other methodologies

Placing MAGERIT in the international landscape helps to appreciate its design choices and to answer competently when somebody asks why this method and not another.

ISO/IEC 27005 offers guidance for managing information security risks within a management system conforming to ISO/IEC 27001, without prescribing a specific calculation method. MAGERIT fits within that framework and supplies what the standard deliberately withholds: a detailed procedure and a ready-to-use catalogue of elements. The ISO 31000 family operates one level up, in the management of risk of any nature across the organisation.

In the United States, NIST Special Publication 800-30 develops the conduct of risk assessments within the federal management framework. France maintains EBIOS Risk Manager, strongly oriented towards attack scenarios and the adversary’s perspective. Germany integrates its risk analysis into the IT-Grundschutz corpus. And in economic quantification of risk, the FAIR model has taken hold, working with probability distributions and monetary estimates under a philosophy quite different from MAGERIT’s.

Academic literature has compared these methods systematically. Shameli-Sendi, Aghababaei-Barzegar and Cheriet (2016) proposed a taxonomy of risk assessment methodologies allowing them to be classified by perspective and level of detail. Wangen, Hallstensen and Snekkenes (2018) developed a framework for estimating method completeness and compared a broad set of them, finding notable differences in coverage of the process phases. And for the Spanish methodology specifically, Vicente, Mateos and Jiménez-Martín (2014) proposed a fuzzy extension of MAGERIT precisely to handle with greater subtlety the imprecision inherent in qualitative valuations.

A reasonable balance emerges from that comparison. MAGERIT stands out for the quality of its catalogue of elements, for the internal coherence of its dependency model and for its direct fit with the Spanish regulatory framework. It lags in the explicit treatment of adversary behaviour, where EBIOS Risk Manager has advanced further, and in economic quantification, where FAIR-type approaches yield results more useful for a conversation with the finance director.

What the methodology does not solve

An honest monograph must give space to the limits, and this method has them.

The first is the subjectivity of the estimates. However many criteria are documented, degradation and frequency are estimated by a person, and different people produce different results for the same system. The method mitigates the problem with shared catalogues and criteria without eliminating it. Reading the results as measurements is an error, as noted earlier.

The second is effort. A rigorous analysis of a medium-sized organisation consumes weeks of work from people who know the systems well and who are usually the same people who operate them. That competition for time explains many mediocre analyses, and the appearance of lightweight variants of the tool is an explicit acknowledgement of the problem.

The third is the ageing of the method itself. The current version was published in 2012, and since then cloud architectures, dependence on managed service providers, the software supply chain and, more recently, the incorporation of artificial intelligence systems into organisational processes have changed substantially. None of that is well represented in a catalogue of assets and threats more than a decade old, and practice has been resolving it through adaptations that depend on each analyst’s judgement.

The fourth is the difficulty of modelling the adversary. The method treats deliberate attacks with the same machinery as accidental events, when their nature differs: an attacker observes, learns and chooses the moment and the target. Approaches based on attack scenarios and on the study of adversary tactics and techniques complement this point well, and that is the direction in which more recent methodologies are moving.

Acknowledging these limits does not diminish the method. An imperfect but honest analysis, reviewed and signed by the right people, remains infinitely more useful —and more defensible— than the absence of any analysis, which is the real situation of a great many organisations.

Knowing what is at stake

The ultimate usefulness of MAGERIT and PILAR lies not in the numbers they produce but in the conversation they force. Determining which information and which services genuinely matter, who answers for them, which pieces they depend on, what can go wrong and what is being done about it is an exercise no organisation undertakes spontaneously. The methodology supplies the script for that conversation and, above all, leaves a written, dated record of what was said and who decided it.

For criminology and forensic science practitioners, that document is a source of the first order. It describes the system’s architecture, points to its known weaknesses, reveals what was known and since when, and shows what the organisation decided to do with that knowledge. Reading it well requires understanding its vocabulary and its conventions, which is what we have tried to offer in these pages.

With this instalment, the series has covered the CCN guide catalogue, the annotated selection of those most useful in investigation, a practical case of forensic readiness, the cyber intelligence guide, the incident management guide, the agency’s tool ecosystem, the comparison with international hardening standards and, now, the risk methodology. The next subjects are already on the table: the forensic analysis of malicious code, with guide CCN-STIC-834 as its reference, and moving forensic readiness into the Windows and Active Directory environment, where most organisations actually work.

Aviso sobre el uso responsable de la Inteligencia Artificial Como entidad orientada a la investigación, promoción y uso social de nuevas tecnologías en nuestros campos de actuación, impulsamos el uso responsable de la IA para evitar la saturación de contenidos de baja calidad y el abuso a la confianza del usuario. Este artículo ha sido creado enteramente por redactores y revisores, se emplea corrección, revisión avanzada y diseño de esquemas con modelos especializados de IA entrenados en nuestro campo para garantizar principalmente, la revisión de elementos técnicos tales como el análisis de la funcionalidad de las líneas de código, razonamientos complejos en áreas técnicas específicas o la verificación de los enlaces a las fuentes bibliográficas, junto con elementos menores de estilo, sintaxis y gramática. Aplicando así la IA de manera que aumente la calidad del producto y ejemplificando una filosofía éticamente responsable, honesta y transparente con el usuario que además ayuda a entender las capacidades de los modelos de frontera en asistencia técnica. Para la revisión técnica de este trabajo se ha empleado un modelo abliterated para evitar restricciones en la verificación del código. Ollama-Open Code con Huihui-Qwen3.6-35B-A3B-abliterated Base de conocimiento y entrenamiento para revisión: AF_QB_EVAL-ablt_rev_6 29_08_2026.md AF_QB_EVAL_GRAPH_SINTAX_ablt_rev_6 29_08_2026.md Ventana de contexto alcanzada en avaluación: 630.4k (256K x2 (comprimidas) +118.4k Modo evaluador de correcciones (LLM-as-a-judge) enfrentado a Qwen3.6: Anthropic Fable 5.1 Esfuerzo: Max Ventana de contexto alcanzada en avaluación:901.6k Base de conocimiento y entrenamiento para segunda evaluación: AF_QB_EVAL2_rev_6 29_08_2026.md AF_QB_EVAL-GRAPH_SINTAX-EVAL2_rev_6 29_08_2026.md

Bibliografía y fuentes · References

Centro Criptológico Nacional. (s. f.). PILAR. Análisis y gestión de riesgos. CCN-CERT. https://pilar.ccn-cert.cni.es

Centro Criptológico Nacional. (s. f.). CCN-STIC-470. PILAR — Manual de usuario. Serie CCN-STIC, guías de acceso público. https://www.ccn-cert.cni.es

Centro Criptológico Nacional. (s. f.). CCN-STIC-472. PILAR Basic — Manual de usuario. Serie CCN-STIC, guías de acceso público. https://www.ccn-cert.cni.es

Centro Criptológico Nacional. (s. f.). CCN-STIC-473. µPILAR — Manual de usuario. Serie CCN-STIC, guías de acceso público. https://www.ccn-cert.cni.es

Fenz, S., Heurix, J., Neubauer, T., & Pechstein, F. (2014). Current challenges in information security risk management. Information Management & Computer Security, 22(5), 410-430. https://doi.org/10.1108/IMCS-07-2013-0053

International Organization for Standardization. (2018). ISO 31000:2018. Risk management — Guidelines. ISO.

International Organization for Standardization & International Electrotechnical Commission. (2022). ISO/IEC 27005:2022. Information security, cybersecurity and privacy protection — Guidance on managing information security risks. ISO/IEC.

Ministerio de Hacienda y Administraciones Públicas. (2012). MAGERIT versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro I: Método. Gobierno de España.

Ministerio de Hacienda y Administraciones Públicas. (2012). MAGERIT versión 3.0. Libro II: Catálogo de Elementos. Gobierno de España.

Ministerio de Hacienda y Administraciones Públicas. (2012). MAGERIT versión 3.0. Libro III: Guía de Técnicas. Gobierno de España.

National Institute of Standards and Technology. (2012). Guide for conducting risk assessments (NIST Special Publication 800-30, Rev. 1). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-30r1

Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Boletín Oficial del Estado, 106, de 4 de mayo de 2022.

Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos (RGPD). Diario Oficial de la Unión Europea, L 119, de 4 de mayo de 2016.

Shameli-Sendi, A., Aghababaei-Barzegar, R., & Cheriet, M. (2016). Taxonomy of information security risk assessment (ISRA). Computers & Security, 57, 14-30. https://doi.org/10.1016/j.cose.2015.11.001

Vicente, E., Mateos, A., & Jiménez-Martín, A. (2014). Risk analysis in information systems: A fuzzification of the MAGERIT methodology. Knowledge-Based Systems, 66, 1-12. https://doi.org/10.1016/j.knosys.2014.02.018

Wangen, G., Hallstensen, C., & Snekkenes, E. (2018). A framework for estimating information security risk assessment method completeness. International Journal of Information Security, 17(6), 681-699. https://doi.org/10.1007/s10207-017-0382-0

Créditos de las imágenes

Todos los esquemas y la imagen de portada de este artículo son de elaboración propia para Actum Forense Press, realizados a partir de la documentación pública citada en la bibliografía. Se publican bajo la misma licencia que el resto de los contenidos originales de la revista.

Nota sobre la fecha de las fuentes: la información sobre versiones de la metodología y de la herramienta está referida a agosto de 2026. Conviene comprobar la vigencia de cada referencia antes de emplearla en un informe.