1. INTRODUCCIÓN Y ENCUADRE

El análisis y la gestión de riesgos constituyen el mecanismo que transforma la seguridad de la información en una disciplina de gobierno. Una organización no puede proteger de la misma manera todos sus datos, servicios, aplicaciones, equipos, instalaciones y proveedores: los recursos son limitados, los activos tienen valores distintos y las amenazas no se materializan con la misma frecuencia ni causan el mismo daño. El propósito del análisis de riesgos es construir una representación razonada del sistema para saber qué debe protegerse, frente a qué, con qué prioridad y hasta qué nivel.

En el ámbito sanitario esta necesidad es especialmente visible. Un sistema clínico puede manejar información de salud, soportar decisiones asistenciales, coordinar profesionales, intercambiar datos con laboratorios o farmacia y permanecer disponible durante las veinticuatro horas. La pérdida de confidencialidad puede afectar a derechos fundamentales; una alteración no detectada puede comprometer la integridad de la información clínica; una indisponibilidad prolongada puede interrumpir procesos asistenciales; y la ausencia de autenticidad o trazabilidad puede impedir atribuir correctamente una actuación. El análisis debe contemplar simultáneamente estas dimensiones y evitar la simplificación de reducir la seguridad al cifrado o a la instalación de herramientas.

MAGERIT, acrónimo de Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información, nació en los órganos superiores responsables de política informática de la Administración española. El enunciado oficial del tema conserva la referencia histórica al Consejo Superior de Informática; la versión 3 fue publicada en 2012 bajo el entonces Consejo Superior de Administración Electrónica. MAGERIT v3 proporciona un método, un catálogo de elementos y una guía de técnicas. Continúa siendo una referencia pública de especial interés para el sector público, aunque el Real Decreto 311/2022 no impone MAGERIT ni PILAR de forma exclusiva: exige que cada organización realice su propia gestión de riesgos empleando una metodología reconocida internacionalmente.

La metodología distingue dos grandes actividades. El análisis de riesgos determina qué tiene la organización, cuánto importa, a qué amenazas está expuesto, qué protección existe y cuál es el estado de impacto y riesgo. El tratamiento de los riesgos permite adoptar decisiones sobre la exposición detectada: eliminarla cuando sea posible, mitigarla mediante salvaguardas, compartir determinadas consecuencias o financiar su eventual materialización. Una vez calculado el riesgo residual, la organización puede además decidir su aceptación formal conforme a sus criterios y responsabilidades.

El tema también aborda el plan de seguridad, entendido en MAGERIT como la traducción de las decisiones de tratamiento a programas y proyectos concretos, con prioridades, responsables, recursos, calendario e indicadores. No debe confundirse con la política de seguridad: la política establece principios, roles y directrices; el plan ordena actuaciones para alcanzar un estado objetivo de protección.

PILAR es un conjunto de herramientas de Entorno de Análisis de Riesgos que aplica MAGERIT. Permite construir modelos de activos y dependencias, asociar amenazas, valorar frecuencia y degradación, caracterizar salvaguardas y calcular estados de impacto y riesgo. Además, incorpora módulos relacionados con el ENS, la continuidad y el cumplimiento. La herramienta automatiza cálculos y facilita la trazabilidad, pero no sustituye el conocimiento de los responsables del servicio, de la información, de la seguridad y del sistema.

Para una oposición técnica C1 interesa dominar tres planos. El primero es conceptual: diferenciar activo, amenaza, vulnerabilidad, impacto, riesgo, salvaguarda y riesgo residual. El segundo es operativo: saber levantar un inventario, modelar dependencias, valorar amenazas y salvaguardas, interpretar un resultado y mantenerlo actualizado. El tercero es normativo y de gobierno: comprender cómo el análisis alimenta decisiones, la Declaración de Aplicabilidad del ENS, los proyectos de seguridad, la continuidad y el seguimiento.

2. FUNDAMENTOS Y TERMINOLOGÍA DEL RIESGO

2.1. ¿Qué es el riesgo en seguridad de la información?

Antes de abordar MAGERIT es imprescindible diferenciar con precisión los conceptos que forman un análisis. Amenaza, vulnerabilidad, impacto y riesgo están relacionados, pero no son sinónimos. Buena parte de las preguntas tipo test se construyen precisamente intercambiando estos términos.

RIESGO = función de FRECUENCIA/PROBABILIDAD e IMPACTO

2.2. ¿Por qué necesitamos gestionar los riesgos?

1. Priorización de recursos: los recursos humanos, presupuestarios y técnicos son finitos. El análisis permite concentrar las salvaguardas donde la combinación de valor, exposición y consecuencias hace que el riesgo sea más relevante, evitando proteger todos los activos con idéntica intensidad.
2. Cumplimiento y gobernanza: el ENS exige gestión de riesgos y gradúa la formalidad del análisis según la categoría del sistema; el RGPD obliga a adoptar medidas apropiadas al riesgo para los derechos y libertades, e ISO/IEC 27001 exige un proceso definido de evaluación y tratamiento en el marco de un SGSI. La documentación debe ser proporcional, trazable y coherente con el contexto aplicable.
3. Justificación de inversiones: la incorporación de un SIEM, autenticación multifactor, segmentación, copias inmutables o servicios de respuesta debe vincularse a riesgos concretos y a la reducción esperada de frecuencia, degradación o exposición. Así se puede priorizar técnicamente y justificar el coste.
4. Toma de decisiones: migrar un servicio a nube, habilitar acceso remoto, introducir dispositivos móviles o crear nuevas interconexiones modifica activos, dependencias, superficies de exposición y responsabilidades. El análisis permite comparar alternativas antes de implantar el cambio.
5. Prevención y resiliencia: un incidente grave puede afectar a la continuidad asistencial, la integridad clínica, la confidencialidad y la trazabilidad. Identificar previamente escenarios plausibles permite implantar salvaguardas preventivas, de detección, respuesta y recuperación y comprobar después si el riesgo residual es aceptable.

2.3. Distinciones terminológicas que deben mantenerse

En MAGERIT se utiliza con frecuencia la frecuencia de la amenaza en lugar de una probabilidad abstracta. La frecuencia expresa una tasa esperada de ocurrencia en un periodo. El riesgo se deriva algorítmicamente del impacto y la frecuencia, pero no debe enseñarse como una única multiplicación universal: las escalas cualitativas, dependencias y funciones de valoración pueden requerir tratamientos distintos.

3. MARCO NORMATIVO Y DE GOBIERNO

3.1. Gestión basada en riesgos en el Esquema Nacional de Seguridad

El Real Decreto 311/2022 configura la gestión basada en riesgos como parte del proceso integral de seguridad. Su artículo 14 exige que cada organización que desarrolle o implante sistemas para tratar información o prestar servicios realice su propia gestión de riesgos. Esta gestión se articula mediante el análisis y el tratamiento de los riesgos, empleando una metodología reconocida internacionalmente. La consecuencia práctica es doble: la organización no puede trasladar íntegramente la responsabilidad a un proveedor y tampoco puede justificar medidas mediante fórmulas genéricas sin relacionarlas con el sistema concreto.

La medida op.pl.1 del anexo II desarrolla el análisis de riesgos con niveles crecientes de formalidad. Para categoría BÁSICA se identifican los activos más valiosos, las amenazas más probables, las salvaguardas y los principales riesgos residuales. La categoría MEDIA incorpora el refuerzo R1: análisis semiformal, lenguaje específico, catálogo básico de amenazas, semántica definida, valoración cualitativa de activos, cuantificación de amenazas y valoración del riesgo residual. La categoría ALTA aplica el refuerzo R2: análisis formal con fundamento matemático reconocido, amenazas posibles, priorización de salvaguardas y asunción formal del riesgo residual.

3.2. Política de seguridad, responsabilidades y aceptación del riesgo

La política de seguridad define el marco de gobierno, los roles y la estructura documental. El ENS diferencia al responsable de la información, responsable del servicio, responsable de la seguridad y responsable del sistema. Esta separación es esencial porque la valoración del daño no puede quedar únicamente en manos técnicas: el responsable de la información conoce las consecuencias de una pérdida de confidencialidad o integridad, mientras que el responsable del servicio determina el perjuicio asociado a la interrupción o degradación del servicio.

La aceptación del riesgo residual corresponde a la autoridad con capacidad para asumir sus consecuencias, no al analista ni a la herramienta. El equipo de riesgos aporta una estimación fundamentada; la dirección decide si el nivel residual es aceptable, si exige nuevas salvaguardas o si debe modificarse el alcance del servicio. La aceptación debe documentarse, fijar condiciones y revisarse cuando cambien los supuestos.

3.3. Relación con ISO/IEC 27001, ISO/IEC 27005 y protección de datos

ISO/IEC 27001 exige que el sistema de gestión de seguridad de la información establezca un proceso de evaluación y tratamiento de riesgos coherente y repetible. ISO/IEC 27005 ofrece orientación específica para la gestión de riesgos de seguridad de la información. MAGERIT puede utilizarse como método de evaluación dentro de un SGSI siempre que la organización defina sus criterios de aceptación, mantenga la trazabilidad entre riesgos y controles y revise los resultados.

El análisis de riesgos de seguridad no es idéntico a la evaluación de impacto relativa a la protección de datos. El Reglamento General de Protección de Datos obliga a aplicar medidas apropiadas atendiendo al riesgo para los derechos y libertades de las personas y, cuando un tratamiento pueda entrañar alto riesgo, puede exigir una evaluación de impacto. Ambos trabajos comparten información sobre activos, amenazas, medidas y consecuencias, pero difieren en su objeto: la EIPD se centra en los efectos del tratamiento sobre las personas; MAGERIT analiza el sistema de información y los objetivos de la organización en sus dimensiones de seguridad.

3.4. Ciclo de vida y reevaluación

El análisis no es una fotografía perpetua. El ENS exige vigilancia continua y reevaluación periódica, y MAGERIT insiste en el seguimiento de los supuestos. Debe revisarse ante cambios significativos: incorporación de servicios en la nube, nuevas interconexiones, modificación del modelo de identidad, externalización, actualización relevante de arquitectura, aparición de amenazas, incidentes graves, cambios normativos o alteración del valor de los servicios.

4. MAGERIT: ESTRUCTURA, ALCANCE Y PRODUCTOS

4.1. Naturaleza, finalidad y alcance

MAGERIT es un método estructurado orientado a investigar los riesgos que soportan los sistemas de información y a recomendar medidas apropiadas para mantenerlos bajo control. Su finalidad no es producir una cifra aislada, sino facilitar decisiones de gobierno con una terminología común y una cadena de razonamiento auditable. El método conecta el valor que la organización atribuye a su información y servicios con las amenazas, las salvaguardas y los estados de impacto y riesgo.

La metodología resulta aplicable a sistemas en proyecto y a sistemas en explotación. Aplicarla durante el diseño permite incorporar requisitos de seguridad, continuidad, registro, identidad y arquitectura antes de que las decisiones sean costosas de modificar. En explotación, permite revisar si las salvaguardas continúan siendo eficaces, priorizar actuaciones y justificar inversiones.

4.2. Los tres libros de MAGERIT v3

Los catálogos son ayudas, no listas cerradas. Un análisis correcto adapta los tipos de activos, amenazas y salvaguardas al contexto. Copiar sin criterio el catálogo produce modelos voluminosos y poco útiles; omitir elementos relevantes por no aparecer literalmente en él produce una falsa sensación de exhaustividad.

4.3. Dos niveles: proceso de gestión y proyecto de análisis

MAGERIT diferencia el proceso continuo de gestión de riesgos de los proyectos que construyen o renuevan la base del análisis. La gestión establece el contexto, los criterios de evaluación y aceptación, analiza y trata riesgos, comunica las decisiones y supervisa cambios. Un proyecto de análisis, denominado PAR, organiza el trabajo intensivo necesario para disponer de un modelo fiable.

4.4. Proyecto PAR y método MAR

El proyecto PAR comprende actividades preliminares, elaboración y comunicación. Las preliminares incluyen el estudio de oportunidad, la determinación del alcance, la planificación y el lanzamiento. El método de análisis de riesgos, MAR, se estructura en caracterización de activos, amenazas y salvaguardas, y estimación del estado de riesgo. Esta nomenclatura es especialmente preguntable porque permite distinguir tareas metodológicas de actividades económicas o de gestión de proyectos.

4.5. Productos y trazabilidad

Entre los productos se encuentran el modelo de valor, el mapa de amenazas, la declaración de aplicabilidad de salvaguardas, la valoración de su eficacia, los informes de impacto y riesgo, el informe de insuficiencias y el plan de seguridad. La calidad no depende de acumular documentos, sino de que cada conclusión pueda rastrearse hasta las evidencias y criterios utilizados. Un riesgo debe poder relacionarse con los activos afectados, las amenazas, las valoraciones, las salvaguardas existentes, las actuaciones previstas y el responsable que lo acepta.

5. ACTIVOS, DEPENDENCIAS Y VALORACIÓN

5.1. Activos

Los activos son el núcleo del análisis de riesgos. El enfoque operativo correcto no consiste en empezar haciendo una lista de servidores, sino en identificar primero qué información y qué servicios son necesarios para la misión y, a partir de ellos, qué recursos los soportan.

5.2. Valoración de activos

Valorar un activo no equivale a asignarle su precio de adquisición. Un servidor puede costar relativamente poco y soportar un servicio de altísima criticidad. Lo que interesa es valorar las consecuencias que tendría la pérdida o degradación de las propiedades de seguridad de la información y del servicio.

MAGERIT trabaja con cinco dimensiones:

• [C] Confidencialidad: daño derivado de que la información sea conocida por quien no debe. En datos de salud la consecuencia puede afectar gravemente a la privacidad y al cumplimiento normativo.
• [I] Integridad: daño derivado de una alteración no autorizada o incorrecta. En un dato clínico, de prescripción o resultado diagnóstico, la pérdida de integridad puede afectar directamente a la seguridad del proceso asistencial.
• [D] Disponibilidad: perjuicio causado por no disponer de la información o del servicio cuando se necesita. La valoración debe relacionarse con el proceso y con la duración de la interrupción.
• [A] Autenticidad: perjuicio derivado de no poder garantizar que una entidad es quien dice ser o que la fuente de los datos es la declarada.
• [T] Trazabilidad: daño provocado por no poder reconstruir quién hizo qué y cuándo. Es esencial para investigación de incidentes, auditoría y atribución de acciones.

Ejemplo cualitativo didáctico de un activo esencial:

Confidencialidad : ALTA
Integridad       : MUY ALTA
Disponibilidad   : ALTA
Autenticidad     : ALTA
Trazabilidad     : ALTA

La escala y sus criterios deben definirse antes de valorar
y aplicarse de forma homogénea.

5.3. Dependencias, valor propio y valor acumulado

Las dependencias permiten trasladar el valor de los activos esenciales a los activos que los soportan. Un servidor puede no tener un valor propio elevado para la misión, pero acumular un valor muy alto porque de él dependen varios servicios clínicos. Esta propagación evita infravalorar infraestructuras, identidades, comunicaciones o personas que, consideradas aisladamente, parecerían reemplazables.

La dependencia debe modelarse por dimensión. Una aplicación puede depender totalmente de una base de datos para integridad y disponibilidad, pero solo parcialmente de un componente de presentación para confidencialidad. La simplificación de usar una única relación para todas las dimensiones puede distorsionar el resultado.

6. AMENAZAS, VULNERABILIDADES, FRECUENCIA Y DEGRADACIÓN

6.1. Amenazas y catálogo de MAGERIT

Una amenaza es una causa potencial de un incidente que puede perjudicar a uno o varios activos. MAGERIT v3 utiliza el catálogo del Libro II como ayuda sistemática para no olvidar escenarios relevantes. No debe confundirse catálogo con predicción: que una amenaza figure en el libro no significa que sea aplicable a todos los activos, y que una amenaza nueva no figure literalmente no impide incorporarla al análisis.

El catálogo agrupa amenazas en cuatro grandes familias: [N] desastres naturales, [I] de origen industrial, [E] errores y fallos no intencionados y [A] ataques intencionados. Una particularidad que puede inducir a error es que “Fuego” y “Daños por agua” aparecen tanto en el grupo natural como en el industrial, porque el origen causal puede ser distinto.

6.2. Vulnerabilidad: concepto y uso prudente

Una vulnerabilidad es una debilidad o condición que facilita que una amenaza produzca daño o aumente sus consecuencias. Puede ser técnica, organizativa, física o humana: software sin soporte, una configuración insegura, privilegios excesivos, un procedimiento incompleto, ausencia de segregación, una sala sin controles físicos suficientes o formación deficiente. En la práctica se localiza mediante inventarios, revisión de configuración, gestión de vulnerabilidades, auditorías, pruebas, incidentes y conocimiento del proceso.

Conviene evitar una formulación demasiado rígida: no toda amenaza necesita una “vulnerabilidad” explícitamente inventariada para materializarse. Un desastre natural puede ocurrir aunque el sistema esté correctamente administrado. Lo relevante es que las debilidades y la eficacia de las salvaguardas modifican la exposición, la frecuencia esperada o la degradación resultante. En la terminología operativa de PILAR, frecuencia y degradación ayudan a caracterizar la vulnerabilidad del sistema frente a la amenaza.

6.3. Frecuencia

La frecuencia expresa cuántas veces se espera que se materialice una amenaza en un periodo. Puede estimarse con series históricas, estadísticas fiables, inteligencia de amenazas, registros de incidentes, telemetría, información de proveedores o juicio experto. Si no hay datos sólidos, es preferible una escala cualitativa bien definida a un porcentaje con falsa precisión.

Para un técnico C1, la operación consiste en documentar de dónde sale la estimación. No basta escribir “alta” porque el analista lo crea: debe indicarse si se apoya en incidentes registrados, exposición a Internet, número de usuarios, antigüedad del componente, historial de fallos, avisos del fabricante, vulnerabilidades conocidas u otra evidencia. El dato debe poder revisarse cuando cambie el entorno.

6.4. Degradación

La degradación indica cuánto pierde el activo cuando la amenaza se materializa. Puede ser total o parcial y puede variar por dimensión. Un corte de comunicaciones puede afectar principalmente a disponibilidad; una alteración de un registro afecta a integridad; una divulgación no autorizada afecta a confidencialidad. El tiempo también puede modificar la degradación: cinco minutos de indisponibilidad no necesariamente producen el mismo daño que varias horas.

En un análisis maduro se evita describir el escenario con una sola etiqueta. Se documenta el alcance: número de usuarios o centros afectados, duración, reversibilidad, volumen de información, posibilidad de detectar la alteración, dependencia con otros servicios y consecuencias sobre los procesos. Esta descripción mejora tanto la estimación de impacto como la selección posterior de salvaguardas.

7. SALVAGUARDAS, EFICACIA Y MADUREZ

7.1. Salvaguardas

Las salvaguardas o contramedidas son controles destinados a modificar el riesgo. No todas actúan de la misma forma ni en el mismo momento del incidente.

1. Reducir la frecuencia o probabilidad de materialización: por ejemplo, endurecimiento de configuración, autenticación robusta, mínimo privilegio o segmentación.
2. Reducir la degradación o consecuencias: por ejemplo, alta disponibilidad, copias de seguridad recuperables, redundancia o procedimientos de contingencia.
3. Detectar y facilitar una respuesta temprana: por ejemplo, monitorización, registros, SIEM, IDS o alertas operativas.

MAGERIT dispone en su catálogo de grupos de salvaguardas que cubren ámbitos organizativos, físicos, técnicos y operativos. Al trabajar con un sistema sometido al ENS, estas salvaguardas deben relacionarse además con las medidas del Anexo II que correspondan a su categoría y riesgos:

7.2. Salvaguardas sobre frecuencia y degradación

Una misma salvaguarda puede tener varios efectos. La autenticación multifactor disminuye la probabilidad de que el robo de una contraseña permita un acceso efectivo. La segmentación puede reducir tanto la probabilidad de propagación como la extensión del daño. Una copia de seguridad no impide que se destruya información, pero puede reducir fuertemente la degradación si permite restaurarla de forma fiable.

La clasificación por función ayuda a interpretar preguntas de examen. Las salvaguardas preventivas, disuasorias o eliminatorias actúan principalmente antes del incidente. Las minimizadoras, correctivas y de recuperación reducen las consecuencias una vez materializado. Las de detección y reacción permiten acortar el tiempo entre el inicio del incidente y la respuesta.

7.3. Eficacia, cobertura y madurez

La existencia nominal de una salvaguarda no implica eficacia. Debe valorarse su cobertura, grado de implantación, operación, supervisión y capacidad para reducir la amenaza concreta. Un procedimiento aprobado pero desconocido por los usuarios tiene baja eficacia; una copia de seguridad no probada no garantiza recuperación; un registro que no se revisa aporta trazabilidad limitada.

La madurez puede representarse mediante niveles de proceso, pero no debe confundirse con el efecto técnico. Una salvaguarda madura puede no cubrir todos los activos, y una tecnología avanzada puede operar con baja madurez. La estimación debe justificar cómo afecta a la frecuencia y a la degradación.

Para valorar una salvaguarda conviene comprobar, al menos:

• que existe formalmente cuando debe existir;
• que cubre los activos previstos;
• que está correctamente configurada;
• que funciona durante la operación normal;
• que produce evidencias verificables;
• que se mantiene y actualiza;
• que se prueba cuando su función exige recuperación o contingencia;
• y que su efecto puede relacionarse con los escenarios de riesgo que pretende tratar.

8. MÉTODO DE ANÁLISIS DE RIESGOS MAR

8.1. Estructura canónica

El Método de Análisis de Riesgos (MAR) de MAGERIT v3 se formaliza en cuatro actividades. Conocer sus nombres y subtareas evita confundir el análisis con el tratamiento o con el plan de seguridad. El análisis construye el modelo y estima el estado de riesgo; la decisión sobre qué hacer con ese riesgo pertenece al proceso de gestión posterior.

8.2. MAR.1: caracterización de los activos

El técnico comienza delimitando el sistema y registrando los activos relevantes. Conviene partir de información y servicios esenciales y descender hacia sus soportes: aplicaciones, bases de datos, identidad, comunicaciones, equipos, soportes, instalaciones y personas. Si se empieza exclusivamente por una lista de servidores se corre el riesgo de describir infraestructura sin entender qué misión sostiene.

La subtarea MAR.12 modela dependencias. El objetivo es responder preguntas como: ¿qué servicio deja de funcionar si falla este componente?, ¿qué dato pierde integridad si una interfaz altera mensajes?, ¿qué servicio depende del directorio de identidades?, ¿qué dependencias externas existen? Estas relaciones permiten acumular valor en activos de soporte y localizar puntos cuya criticidad no se deduce del precio de adquisición.

MAR.13 valora los activos por las dimensiones pertinentes. La escala puede ser cualitativa o cuantitativa, pero debe tener semántica explícita. En un taller de valoración es más importante que cinco participantes entiendan de la misma forma “alto” que disponer de una cifra aparentemente precisa sin criterio compartido.

Inventario operativo mínimo de un activo

- Identificador y nombre
- Tipo de activo
- Propietario o responsable funcional/técnico
- Servicio o información a la que da soporte
- Dependencias de entrada y salida
- Ubicación o dominio
- Dimensiones relevantes
- Valoración y justificación
- Evidencias y fecha de revisión

8.3. MAR.2: caracterización de las amenazas

Con los activos caracterizados se seleccionan amenazas pertinentes. MAR.21 evita omisiones usando el catálogo como guía; MAR.22 valora la amenaza mediante su frecuencia y la degradación que produciría. El análisis debe ajustarse al activo concreto: una amenaza debe evaluarse atendiendo a su exposición real, al modo de utilización del activo y a las evidencias disponibles.

En operación, las fuentes de evidencia incluyen registros de incidentes, vulnerabilidades publicadas, alertas de fabricantes y del CCN, telemetría de seguridad, cambios de exposición, fallos de proveedor y resultados de pruebas. Si una amenaza se vuelve más frecuente o un activo queda más expuesto, debe actualizarse el modelo sin esperar a rehacer el estudio completo.

8.4. MAR.3: caracterización de las salvaguardas

Una salvaguarda se valora por su eficacia real, no por existir en un documento o haber sido adquirida. La identificación debe responder qué amenazas trata y sobre qué activos; la valoración debe considerar despliegue, cobertura, configuración, operación, monitorización, mantenimiento y evidencias. Un control desplegado de forma parcial no tiene la misma eficacia que uno con cobertura completa y supervisada.

MAGERIT distingue entre la pertinencia de una salvaguarda y su grado de implantación. De esta actividad salen elementos muy útiles para la gestión: la declaración de aplicabilidad, la evaluación de las salvaguardas y un informe de insuficiencias o vulnerabilidades del sistema de protección. Estos productos permiten traducir el análisis en actuaciones concretas.

8.5. MAR.4: estimación del estado de riesgo

MAR.41 estima el impacto y MAR.42 el riesgo. MAGERIT diferencia estados potenciales, calculados sin considerar la eficacia de las salvaguardas, y estados residuales, calculados teniendo en cuenta las salvaguardas desplegadas. La comparación entre ambos muestra cuánto reduce realmente la protección y dónde permanecen insuficiencias.

8.6. Aproximaciones sucesivas y mantenimiento

MAGERIT admite trabajar por aproximaciones sucesivas. Una primera iteración localiza activos esenciales y riesgos dominantes; las siguientes refinan dependencias, escalas, amenazas y eficacia de controles. Esta forma de trabajo es especialmente útil cuando el alcance es grande o la documentación inicial es incompleta. Iterar no significa improvisar: cada cambio debe quedar trazado y justificado.

Para el perfil C1, el mantenimiento del modelo es tan importante como el cálculo inicial. Un alta de proveedor, una nueva API, un cambio de red, una migración de base de datos, una nueva autenticación o un incidente puede cambiar dependencias y exposición. El técnico debe saber qué parte del modelo se ve afectada y qué evidencias necesita revisar.

9. ESTIMACIÓN DEL IMPACTO, DEL RIESGO Y SU TRATAMIENTO

9.1. Impacto: qué podría ocurrir

El impacto expresa el daño que causaría la materialización de una amenaza sobre los activos. En un modelo cuantitativo simple puede representarse como una función del valor del activo y de la degradación causada por la amenaza. En un modelo cualitativo se usan escalas con criterios definidos. Lo importante es no mezclar aquí la frecuencia: dos amenazas con idéntico impacto pueden originar riesgos muy distintos si una ocurre con mucha mayor frecuencia.

MAGERIT distingue impacto potencial e impacto residual. El potencial no considera la eficacia de las salvaguardas desplegadas; el residual sí la considera. La diferencia permite comprobar si las medidas reducen las consecuencias del incidente o si solo actúan sobre su frecuencia.

9.2. Riesgo: qué probablemente ocurra

El riesgo combina impacto con frecuencia o probabilidad según el algoritmo y la escala definidos. No debe memorizarse una única multiplicación como si fuera universal. En un análisis cuantitativo puede utilizarse una relación matemática; en uno cualitativo puede emplearse una función o matriz con semántica prefijada. En ambos casos la regla debe fijarse antes de conocer los resultados para evitar ajustar el método a una conclusión deseada.

9.3. Evaluación y criterios de aceptación

Una vez estimado el riesgo residual, la organización lo compara con sus criterios de aceptación. Estos criterios deben formar parte del contexto de gestión: umbrales, obligaciones legales, continuidad, seguridad de las personas, compromisos contractuales, dependencia de terceros o cualquier condición que haga inaceptable una exposición aunque su frecuencia sea baja.

La aceptación es una decisión de gobierno. El analista describe y justifica; los equipos técnicos proponen opciones; la autoridad competente decide conforme al reparto de responsabilidades. Una aceptación seria queda documentada, incluye el alcance de lo aceptado, sus condiciones y una fecha o disparador de revisión. No equivale a no actuar por falta de tiempo.

9.4. Opciones de tratamiento en MAGERIT

MAGERIT v3 utiliza una terminología que conviene memorizar: eliminación, mitigación, compartición y financiación. En otros marcos pueden encontrarse expresiones próximas como evitar, reducir, compartir o retener. Cuando una pregunta cite expresamente MAGERIT, conviene responder con la terminología propia de la metodología.

Compartir o financiar no borra automáticamente la responsabilidad de la organización. En un servicio externalizado siguen existiendo deberes de gobierno, control contractual, continuidad, protección de datos y cumplimiento del ENS cuando resulte aplicable. El riesgo de dependencia del proveedor también debe analizarse.

9.5. Salvaguardas que actúan sobre frecuencia o degradación

Las salvaguardas pueden actuar antes, durante o después del incidente. Algunas disminuyen la probabilidad de materialización; otras limitan la degradación; muchas hacen ambas cosas. Por ejemplo, una autenticación robusta reduce la probabilidad de uso indebido de credenciales; la segmentación limita la propagación; una copia de seguridad probada reduce el daño de una pérdida y acelera la recuperación; el registro y la monitorización mejoran detección y respuesta.

9.6. Priorización

No todos los tratamientos pueden ejecutarse simultáneamente. La priorización combina riesgo residual, urgencia, dependencia entre proyectos, coste, recursos disponibles, complejidad, ventanas de cambio y riesgo de transición. Los riesgos que afectan a activos esenciales y exceden claramente el umbral deben elevarse a decisión; los controles de implantación rápida y alto efecto pueden convertirse en acciones tempranas mientras se preparan proyectos estructurales.

El técnico debe distinguir prioridad de riesgo de prioridad de ejecución. Una medida crítica puede requerir una adquisición larga; durante ese periodo pueden necesitarse medidas compensatorias. El análisis proporciona el porqué; el plan de seguridad transforma ese porqué en acciones ordenadas.

10. MODELOS CUALITATIVO, CUANTITATIVO Y TÉCNICAS DE ANÁLISIS

10.1. Modelo cualitativo

El análisis cualitativo trabaja con escalas ordinales: muy bajo, bajo, medio, alto y muy alto, o escalas numéricas que representan categorías y no importes económicos. Su rigor depende de que cada nivel tenga una semántica explícita. “Alto” debe significar lo mismo para todos los participantes y poder justificarse mediante consecuencias observables.

Su principal ventaja es que permite analizar sistemas complejos cuando no existen series históricas suficientes para convertir todas las pérdidas en dinero. Es eficaz para priorizar, comunicar y realizar talleres con responsables funcionales. Su principal riesgo es la subjetividad: si no hay criterios, dos equipos pueden asignar valores incompatibles. Para controlarla se usan guías de valoración, ejemplos, revisión cruzada y consenso.

10.2. Modelo cuantitativo

El análisis cuantitativo utiliza magnitudes numéricas con significado definido, por ejemplo pérdidas monetarias, frecuencias anuales, horas de interrupción o probabilidades. Permite realizar análisis coste-beneficio y comparar alternativas cuando se dispone de datos fiables. El problema no está en la fórmula, sino en la calidad de los datos: una cifra con tres decimales sigue siendo una estimación si se basa en supuestos débiles.

En seguridad es habitual encontrar las métricas SLE (pérdida esperada por evento), ARO (tasa anual de ocurrencia) y ALE (pérdida anual esperada). Una relación habitual es:

ALE = SLE × ARO

Esta expresión es útil para análisis económico, pero no sustituye a MAGERIT ni captura automáticamente consecuencias jurídicas, asistenciales, reputacionales o de seguridad de las personas. Si un impacto no puede convertirse de forma defendible a euros, puede mantenerse como criterio cualitativo o tratarse mediante un modelo mixto.

10.3. Comparación

10.4. Enfoque mixto y aproximaciones sucesivas

En la práctica, un enfoque mixto suele ser razonable: una primera pasada cualitativa identifica activos y escenarios dominantes; después se cuantifican las variables que realmente pueden cambiar una decisión. Esto evita gastar esfuerzo intentando monetizar todos los riesgos y permite concentrarse en los que requieren inversiones o compromisos de servicio importantes.

MAGERIT insiste en las aproximaciones sucesivas. El análisis puede empezar con valores gruesos y refinarse conforme aparecen datos. Lo importante es conservar la trazabilidad: qué se sabía en cada momento, qué hipótesis se modificaron, qué nueva evidencia justificó el cambio y cómo afectó al orden de prioridades.

10.5. Técnicas de apoyo del Libro III

El Libro III de MAGERIT es una Guía de Técnicas. Incluye técnicas específicas para análisis de riesgos, trabajo con tablas, métodos algorítmicos, árboles de ataque y técnicas generales. No todas son obligatorias; se seleccionan según el objetivo, el alcance y el tipo de información disponible.

Las entrevistas permiten descubrir activos, dependencias y consecuencias que no aparecen en inventarios. Los cuestionarios ayudan a recopilar información homogénea en muchas unidades. Las sesiones de trabajo y métodos de consenso permiten calibrar escalas. Los árboles de ataque descomponen cómo un objetivo malicioso puede alcanzarse mediante diferentes caminos, ayudando a identificar puntos de control.

Las tablas activo-amenaza y los diagramas de dependencias favorecen la cobertura sistemática. Los métodos algorítmicos automatizan combinaciones cuando el modelo crece. La técnica debe estar al servicio de la decisión; una representación sofisticada no compensa activos mal definidos ni salvaguardas valoradas sin evidencia.

10.6. Análisis de sensibilidad

El análisis de sensibilidad modifica uno o varios supuestos y observa cómo cambia el resultado. Es especialmente útil cuando la frecuencia de una amenaza o la eficacia de una salvaguarda tienen gran incertidumbre. Si un pequeño cambio altera por completo la prioridad, conviene obtener más evidencia antes de comprometer una inversión importante.

Una práctica sencilla es recalcular el escenario con valores bajo, esperado y alto para las variables inciertas. Otra es comparar varias eficacias de una salvaguarda. El objetivo no es adivinar el futuro, sino saber si la decisión es robusta. Esta disciplina también reduce la tentación de escoger un único número porque “queda bien” en un informe.

11. EL PLAN DE SEGURIDAD

11.1. Concepto en MAGERIT

En MAGERIT v3, el plan de seguridad es el mecanismo que materializa las decisiones adoptadas en el tratamiento de los riesgos. No debe confundirse con la política de seguridad ni con el propio análisis. La política fija principios y organización; el análisis explica el estado de exposición; el plan transforma la decisión en programas y proyectos ejecutables.

El Libro I indica que estos planes pueden recibir nombres distintos según el contexto: plan de mejora de la seguridad, plan director, plan estratégico o plan de adecuación. Lo esencial no es el rótulo, sino que exista una cadena trazable entre riesgo, decisión, salvaguarda, proyecto, responsable, recurso, plazo y comprobación de eficacia.

11.2. Tarea PS.1: identificación de proyectos de seguridad

PS.1 traduce las decisiones de tratamiento en acciones concretas y busca elaborar un conjunto armónico de programas de seguridad. Un programa agrupa tareas que conviene ejecutar conjuntamente porque comparten objetivo, tecnología, responsable, dependencia o ventana de implantación. El producto principal es la relación de programas y proyectos.

Desde el punto de vista operativo, cada proyecto debería vincularse con uno o más riesgos y describir qué salvaguarda implanta o mejora. Debe evitarse una lista genérica de compras: “adquirir un SIEM” no es por sí solo una respuesta de riesgo. Hay que indicar qué escenarios se pretende detectar, qué fuentes de eventos se integrarán, qué cobertura se espera y cómo se medirá la mejora.

11.3. Tarea PS.2: plan de ejecución

PS.2 ordena temporalmente los programas. MAGERIT considera factores como criticidad, coste, disponibilidad de personal, presupuesto, relaciones con otras organizaciones y evolución del marco legal o contractual. Su salida característica es el cronograma de ejecución del plan.

En la práctica conviene registrar dependencias entre proyectos. Una autenticación reforzada puede necesitar previamente federación de identidades; una nueva copia inmutable puede requerir almacenamiento, red y pruebas de restauración; una segmentación puede depender del inventario de flujos. Si se ignoran estas relaciones, el plan acumula fechas irreales y controles parcialmente implantados.

11.4. Tarea PS.3: ejecución

PS.3 ejecuta el plan y busca alcanzar los objetivos de cada proyecto. Entre sus resultados figuran salvaguardas implantadas, normas de uso, procedimientos de operación, indicadores y actualización del modelo de valor, del mapa de riesgos y del estado de riesgo. Esta última parte es esencial: un proyecto no se cierra solo porque la herramienta esté instalada; debe reflejarse el nuevo estado y verificarse su eficacia.

La transición a operación incluye documentación, formación, monitorización, gestión de cambios, respaldo, mantenimiento y responsables. En sistemas críticos también deben definirse criterios de reversión si la implantación falla. El técnico especialista participa de forma directa en estas tareas: configuración, evidencias, pruebas, registro de resultados y comunicación de incidencias.

11.5. Relación con el ENS y la Declaración de Aplicabilidad

El artículo 28 del Real Decreto 311/2022 establece que la selección de medidas depende de activos, categoría y decisiones para gestionar los riesgos. La relación de medidas seleccionadas se formaliza en la Declaración de Aplicabilidad (DoA), firmada por el responsable de la seguridad. Por tanto, análisis, DoA y plan de mejora deben ser coherentes aunque sean documentos distintos.

Si una medida del ENS se sustituye por una compensatoria, la organización debe justificar documentalmente que protege igual o mejor el riesgo y reflejar la correspondencia en la DoA. Esta exigencia refuerza una idea central de MAGERIT: no basta con marcar un control como “cumplido”; debe entenderse qué riesgo trata y con qué eficacia.

11.6. Seguimiento del plan

El plan debe revisarse cuando cambian riesgos, prioridades, presupuesto, arquitectura o eficacia de las medidas. No existe una periodicidad universal que convierta automáticamente en válida una revisión anual; la organización debe establecer su ciclo y, además, reaccionar ante cambios significativos. La revisión debe actualizar tanto el estado de los proyectos como el modelo de riesgo.

Riesgo residual por encima del criterio
        ↓
Decisión de tratamiento
        ↓
PS.1 Programa / proyecto de seguridad
        ↓
PS.2 Prioridad + recursos + calendario
        ↓
PS.3 Implantación + pruebas + indicadores
        ↓
Recalcular impacto y riesgo residual
        ↓
Aceptar, reforzar o replantear

12. LA HERRAMIENTA PILAR

12.1. Concepto y variantes

PILAR es un conjunto de herramientas EAR, Entorno de Análisis de Riesgos, cuya función es analizar y gestionar los riesgos de un sistema de información siguiendo MAGERIT. Está vinculada al Centro Criptológico Nacional y se actualiza periódicamente. El portal oficial distingue la versión íntegra PILAR, PILAR Basic, μPILAR y RMAT para personalización.

Dentro de la versión íntegra se ofrecen dos orientaciones principales. PILAR RM se dedica al análisis y la gestión de riesgos en confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad. PILAR BCM se orienta al análisis de impacto y continuidad de operaciones, incorporando la duración de las interrupciones, elementos de respaldo y planes de recuperación.

El portal oficial consultado en agosto de 2026 mostraba como versión descargable PILAR 2025.1.2, publicada el 28 de marzo de 2025. Como las versiones cambian, para tareas de instalación o soporte debe verificarse siempre el portal oficial antes de descargar, documentar una versión o preparar una actualización.

12.2. Flujo de trabajo en PILAR

El flujo parte de la identificación y valoración de activos. Después se modelan dependencias para propagar el valor de los activos esenciales hacia los activos de soporte. Se asocian amenazas a los tipos de activos y se ajustan frecuencia y degradación conforme a la realidad observada. El sistema calcula impacto y riesgo potencial; posteriormente se identifican y valoran salvaguardas, se estima su madurez o grado de implantación y se obtiene el impacto y riesgo residual.

Activos y dependencias
        ↓
Valor por dimensiones
        ↓
Amenazas: frecuencia + degradación
        ↓
Impacto y riesgo potencial
        ↓
Salvaguardas y madurez
        ↓
Impacto y riesgo residual
        ↓
Plan de tratamiento y seguimiento

El núcleo de la herramienta no es una simple matriz de colores. Mantiene catálogos, asociaciones entre amenazas y activos, reglas de propagación, valoración de salvaguardas y distintos escenarios o etapas de tratamiento. Esto permite comparar el estado actual con estados objetivo y observar cómo cambia el riesgo cuando se implantan programas de seguridad.

12.3. Perfil de seguridad, ENS y Declaración de Aplicabilidad

PILAR incorpora funcionalidades relacionadas con el ENS. Puede servir de apoyo para el análisis, la identificación de requisitos, la evaluación de medidas y la preparación de información necesaria para la Declaración de Aplicabilidad. Sin embargo, ni la categorización ni la responsabilidad sobre la selección de medidas deben delegarse ciegamente en la herramienta.

La Declaración de Aplicabilidad relaciona las medidas seleccionadas y las decisiones que justifican su utilización. Su contenido debe ser coherente con el análisis y con la arquitectura real. Una medida marcada como implantada sin evidencia suficiente constituye un problema de gobierno, aunque una herramienta permita registrarla como tal.

12.4. Ventajas y límites

Entre sus ventajas están la homogeneidad del lenguaje, la reutilización de modelos, el cálculo automatizado, la gestión de dependencias, la comparación de escenarios y la generación de informes. Facilita que un análisis complejo sea mantenible y que las decisiones puedan revisarse. También reduce errores aritméticos y ayuda a documentar el razonamiento.

Sus límites son igualmente importantes. PILAR no conoce por sí sola el valor asistencial de un servicio, la tolerancia a una interrupción, las obligaciones contractuales ni la eficacia real de un procedimiento. Si las entradas son arbitrarias, el resultado también lo será. La herramienta no sustituye entrevistas, revisión de arquitectura, evidencias de operación, pruebas de continuidad ni aceptación por la dirección.

12.5. Uso responsable y mantenimiento del modelo

El modelo debe versionarse, limitar accesos y protegerse porque contiene información sensible sobre activos, dependencias, amenazas y debilidades. Conviene establecer un propietario, un calendario de revisión, un procedimiento de cambio y criterios para incorporar incidentes, vulnerabilidades y modificaciones de arquitectura. Los informes destinados a dirección pueden agregarse; los detalles técnicos deben distribuirse según necesidad de conocer.

13. APLICACIÓN EN EL SERVICIO ANDALUZ DE SALUD

13.1. Particularidades del entorno sanitario

La aplicación al Servicio Andaluz de Salud debe partir de la misión asistencial y de la organización real del sistema analizado. No basta con afirmar que los datos de salud son sensibles. Hay que identificar los servicios concretos, los procesos clínicos y administrativos soportados, los usuarios, las interconexiones, los proveedores, los centros afectados y las consecuencias de una degradación. Un mismo componente puede tener diferente criticidad según el servicio que soporte.

Los activos esenciales suelen ser la información y los servicios. Entre los primeros pueden encontrarse datos identificativos, episodios clínicos, prescripciones, resultados, imágenes, agendas, información de recursos humanos o económica. Entre los servicios, la consulta de información clínica, la prescripción, la citación, la integración con laboratorios, la atención al ciudadano o el soporte a profesionales. Los activos de soporte incluyen aplicaciones, bases de datos, identidad, redes, puestos, CPD, servicios cloud, personal y contratos.

13.2. Organización del análisis

El equipo debe combinar conocimiento funcional y técnico. Participan responsables de la información y del servicio, seguridad, sistemas, explotación, redes, desarrollo, protección de datos, continuidad, contratación y representantes de usuarios. En un sistema asistencial es imprescindible que los profesionales expliquen qué ocurre cuando un dato no está disponible, llega tarde o es incorrecto; los técnicos no pueden inferir por sí solos el impacto clínico.

El alcance debe incluir interconexiones y recursos externos. El ENS mantiene la responsabilidad de la organización aunque utilice servicios de terceros. Por ello, el análisis debe considerar ubicación y jurisdicción, subencargados, niveles de servicio, reversibilidad, portabilidad, gestión de incidentes, continuidad, borrado, evidencias de auditoría y cadena de suministro.

13.3. Caso didáctico: servicio de consulta de resultados

Supóngase un servicio que permite a profesionales autorizados consultar resultados diagnósticos. El activo esencial es la información de resultados y el servicio de consulta. Depende de la aplicación, API de integración, base de datos, sistema de identidad, red corporativa, monitorización, personal de soporte y proveedor de ciertos componentes. Esta dependencia permite comprender que una amenaza sobre el directorio de identidad puede afectar indirectamente al servicio clínico.

Se identifican amenazas como error de asociación, modificación no autorizada, indisponibilidad de la base de datos, fallo de integración, compromiso de credenciales, abuso de privilegios, malware, pérdida de comunicaciones o fallo del proveedor. Para cada una se estima degradación y frecuencia. Las salvaguardas pueden incluir autenticación robusta, mínimo privilegio, segregación, validación de mensajes, controles de integridad, alta disponibilidad, copias, monitorización, registro protegido, pruebas de restauración, procedimientos de contingencia y formación.

13.4. Riesgo de terceros y nube

La utilización de nube no está prohibida de forma general para datos de salud. Debe analizarse el servicio, la ubicación, las transferencias, el contrato, el ENS, las medidas técnicas y organizativas, la continuidad y los derechos de las personas. Que un centro de datos se ubique en otro Estado miembro del Espacio Económico Europeo no constituye por sí solo una transferencia a un tercer país, aunque siguen siendo necesarias las garantías del tratamiento.

13.5. Integración con proyectos y explotación

En nuevos proyectos, el análisis debe iniciarse antes de cerrar la arquitectura y los pliegos. Sus conclusiones alimentan requisitos no funcionales, criterios de aceptación, acuerdos de nivel de servicio, pruebas de seguridad, continuidad, reversibilidad y operación. En explotación, se integra con gestión de cambios, vulnerabilidades, incidentes, capacidad, configuración y continuidad. Un cambio significativo debe desencadenar una revisión del modelo, no limitarse a actualizar un inventario.

13.6. Trabajo operativo del Técnico/a Especialista Informática

La gestión de riesgos no es una actividad reservada a responsables de seguridad o consultores. El personal técnico aporta una parte sustancial de las evidencias que hacen posible un análisis realista. Entre sus tareas pueden encontrarse inventariar componentes, identificar versiones, recoger configuraciones, localizar dependencias técnicas, revisar registros, comprobar copias, documentar enlaces, detectar software obsoleto, ejecutar verificaciones, instalar salvaguardas y registrar el resultado de las pruebas.

Por ejemplo, si el análisis identifica riesgo elevado de pérdida de disponibilidad de una base de datos, el técnico debe poder responder cuestiones muy concretas: ¿existe réplica?, ¿qué ocurre si falla el nodo principal?, ¿cómo se detecta el fallo?, ¿qué procedimiento de conmutación existe?, ¿cuándo se probó?, ¿cuánto tardó?, ¿qué datos podrían perderse?, ¿quién autoriza la recuperación? Las respuestas convierten una valoración abstracta en evidencia.

De igual forma, ante riesgo de acceso no autorizado, el técnico puede aportar información sobre autenticación, grupos, roles, cuentas de servicio, privilegios locales, trazas, caducidad de credenciales, procesos de alta y baja y exposición de interfaces. La gestión de riesgos conecta así con administración de sistemas, redes, bases de datos, desarrollo y soporte.

14. SEGUIMIENTO, REVISIÓN E IDEAS CLAVE

14.1. Del análisis a la decisión

El análisis solo aporta valor si conduce a decisiones claras. Cada riesgo relevante debe tener propietario, decisión de tratamiento, actuaciones, fecha objetivo, recursos, dependencia con otros proyectos y criterio de cierre. La dirección necesita conocer escenarios, tendencias y excepciones; los equipos técnicos necesitan detalles sobre activos, amenazas y salvaguardas. Los informes deben adaptarse a cada audiencia sin romper la trazabilidad.

14.2. Indicadores

Los indicadores pueden medir la ejecución del plan y la evolución del riesgo. Son ejemplos útiles el porcentaje de salvaguardas objetivo implantadas y verificadas, riesgos por encima del umbral, antigüedad de aceptaciones, cumplimiento de hitos, tiempo de corrección de vulnerabilidades críticas, resultados de pruebas de restauración, cobertura de registro, incidentes por escenario y desviaciones de los niveles de servicio. Un indicador debe tener definición, fuente, periodicidad, responsable y umbral.

No debe confundirse actividad con eficacia. Instalar una herramienta o impartir una formación acredita ejecución, pero no necesariamente reducción del riesgo. La eficacia exige comprobar si disminuye la frecuencia, la degradación o la exposición, y si el control funciona bajo condiciones reales.

14.3. Revisión por cambios e incidentes

Los incidentes proporcionan evidencia para recalibrar el modelo. Pueden revelar amenazas omitidas, frecuencias subestimadas, dependencias ocultas o salvaguardas menos eficaces de lo previsto. La revisión posterior debe actualizar datos, no buscar encajar el incidente en el modelo anterior. También deben incorporarse cambios de negocio, tecnología, proveedores, normativa y arquitectura.

14.4. Errores frecuentes

• Confundir vulnerabilidad con amenaza o riesgo.
• Valorar únicamente hardware y olvidar información y servicios esenciales.
• Asignar valores sin criterios comunes ni participación de los responsables.
• Usar una matriz de colores como sustituto del razonamiento.
• Considerar implantada una salvaguarda sin evidencia de eficacia.
• Aceptar riesgos por inacción, sin decisión formal ni fecha de revisión.
• Omitir proveedores, interconexiones y dependencias organizativas.
• No actualizar el análisis después de cambios o incidentes.
• Presentar riesgo como una única multiplicación universal.
• Confundir el análisis de riesgos con la EIPD del RGPD.
• Suponer que PILAR decide automáticamente qué riesgos deben aceptarse.
• Confundir el Plan de Seguridad de MAGERIT con la Declaración de Aplicabilidad del ENS.

14.5. Ideas de repaso

Para el examen, memoriza la secuencia lógica: activos, dependencias y valor; amenazas, frecuencia y degradación; salvaguardas y eficacia; impacto y riesgo; tratamiento y riesgo residual; plan, ejecución y seguimiento. Recuerda las tareas MAR.1 a MAR.4, las tres tareas del plan de seguridad PS.1 a PS.3, los niveles de análisis de op.pl.1 y la función de PILAR como soporte, no como decisor.

15. MAPA CONCEPTUAL