Saltar a contenido

1.2.2.-Análisis de Riesgos

1.2.2. Análisis de riesgos

Idea principal

Analizar riesgos consiste en comprender qué situaciones podrían afectar a los activos y objetivos de una organización, estimar sus consecuencias y decidir cuáles requieren una respuesta. El resultado no es una predicción exacta ni una promesa de riesgo cero: es información razonada para tomar decisiones y priorizar medidas.

En Principios generales de ciberseguridad has visto que la protección debe partir de lo que la organización necesita preservar. En Plan Director de Seguridad has estudiado cómo convertir las necesidades de mejora en iniciativas priorizadas. El análisis de riesgos conecta ambos temas: ayuda a justificar qué conviene proteger primero y por qué.

El objetivo de este tema es que aprendas a delimitar un análisis, relacionar activos con amenazas y debilidades, valorar escenarios con criterios explícitos y proponer un tratamiento adecuado. Después, las medidas seleccionadas pueden concretarse en normas y controles, como los que se trabajan en Protección del puesto de trabajo.

Código Descripción
Objetivo general e Elaborar análisis de riesgos para identificar activos, amenazas, vulnerabilidades y medidas de seguridad.
RA 1 (relación indirecta) Desarrolla planes de prevención y concienciación en ciberseguridad, estableciendo normas y medidas de protección.
CE 1.a (relación indirecta) Se han definido los principios generales de la organización en materia de ciberseguridad, que deben ser conocidos y apoyados por la dirección de la misma.

La normativa del módulo no incluye en el RA 1 un criterio de evaluación específico sobre la elaboración del análisis de riesgos. Por ello, el vínculo con el RA 1 y el CE 1.a es de apoyo: este análisis aporta información para tomar decisiones preventivas, pero no sustituye la evaluación directa de esos criterios.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

  • delimitar el alcance de un análisis y documentar sus límites;
  • identificar activos, amenazas, vulnerabilidades y salvaguardas relevantes;
  • estimar probabilidad e impacto con criterios comprensibles y justificar el nivel de riesgo;
  • comparar alternativas de tratamiento y registrar el riesgo que queda;
  • explicar cómo los resultados alimentan el Plan Director de Seguridad.

Mapa del tema

Seguiremos esta secuencia:

  1. situar el análisis de riesgos dentro de la gestión de seguridad;
  2. definir el alcance e identificar activos y escenarios;
  3. analizar amenazas, vulnerabilidades y salvaguardas;
  4. estimar y evaluar el riesgo;
  5. decidir el tratamiento y comunicar los resultados.

El análisis se revisa con una periodicidad definida por la organización y también cuando cambia el contexto; no se hace una sola vez:

flowchart LR
  A["1. Definir el alcance"] --> B["2. Identificar activos"]
  B --> C["3. Describir escenarios"]
  C --> D["4. Revisar debilidades y controles"]
  D --> E["5. Estimar probabilidad e impacto"]
  E --> F["6. Tratar y evaluar el riesgo residual"]
  F --> G["Incorporar iniciativas al PDS"]
  G --> H["Revisar ante cambios"]
  H --> A

La guía de INCIBE organiza el análisis en seis fases. Los títulos de los apartados 2–5 indican la fase de referencia; el diagrama desglosa algunas tareas y muestra cómo los resultados se incorporan al PDS y se revisan ante cambios.

1. Para qué sirve un análisis de riesgos

Una organización depende de procesos, información, personas, instalaciones, sistemas y proveedores. Si uno de esos elementos se pierde, se altera, queda expuesto o deja de estar disponible, puede haber interrupciones, costes, daños a la reputación o consecuencias legales y contractuales. No todos los activos tienen la misma importancia ni todas las amenazas son igual de relevantes.

Un análisis de riesgos estudia esas situaciones para que la organización pueda decidir qué debe atender antes, qué medidas son proporcionadas y qué riesgo puede aceptar de forma consciente. Puede realizarse como trabajo independiente o como parte del diagnóstico que alimenta un PDS. En este último caso, los resultados ayudan a justificar, definir y priorizar proyectos de seguridad.

Conviene distinguir el análisis —identificar escenarios y comprender su probabilidad y consecuencias— de la gestión del riesgo, que también incluye decidir y ejecutar tratamientos, aceptar el riesgo que queda y revisar las decisiones. En este tema se presenta un ciclo práctico que incorpora ambas partes. Las metodologías pueden organizar las actividades con nombres u orden distintos.

Riesgo

Efecto de la incertidumbre sobre los objetivos de la organización. En un análisis práctico se describe mediante escenarios y se estima atendiendo, como mínimo, a la posibilidad de que ocurran y a las consecuencias que tendrían.

Concepto Qué significa Ejemplo relacionado con un ERP
Activo Elemento que tiene valor para un proceso u objetivo. Los datos de pedidos y el servicio que permite consultarlos.
Amenaza Suceso o circunstancia que puede causar daño a un activo. Un ataque de ransomware o una avería del almacenamiento.
Vulnerabilidad Debilidad que puede facilitar que una amenaza produzca daño. Un servidor sin actualizaciones de seguridad.
Salvaguarda o control Medida que reduce la probabilidad o las consecuencias de un escenario. Copias separadas y pruebas de restauración.
Incidente Suceso que ya ha ocurrido y ha afectado a la seguridad o al servicio. El ERP ha quedado cifrado y no permite tramitar pedidos.

Riesgo e incidente no son lo mismo

Antes de que ocurra, se analiza el riesgo de que el ERP quede indisponible. Si el servicio ya se ha interrumpido, se gestiona un incidente. El análisis de riesgos ayuda a prepararse; no sustituye los procedimientos de detección y respuesta a incidentes.

2. Fases 1 y 2: definir el alcance e identificar los activos

2.1. Fase 1: definir el alcance

El alcance especifica qué organización, proceso, departamento, servicio, sistema o información se estudia, y qué queda fuera. Puede comprender toda la organización o centrarse, por ejemplo, en los procesos de Administración, la producción y el almacén, o los sistemas que prestan servicio a una página web.

El análisis debe ser coherente con el objetivo y los recursos disponibles. Un alcance acotado y documentado suele resultar más útil que intentar abarcarlo todo de forma superficial. Si se hace dentro de un PDS, conviene que cubra el alcance acordado para ese plan; un análisis independiente puede tener límites distintos.

Al definirlo, registra:

  • procesos y servicios que se quieren proteger;
  • departamentos, sistemas, sedes, datos y terceros incluidos;
  • dependencias importantes, como redes, servicios en la nube o proveedores;
  • exclusiones y motivos por los que se dejan fuera;
  • personas responsables y criterios generales para considerar aceptable un riesgo.

Por ejemplo, el alcance podría ser «los servicios y sistemas del Departamento de Informática». Se pueden incluir los servidores, la red corporativa, las copias de seguridad y los accesos remotos; si los sistemas de producción industrial quedan fuera, esa exclusión debe quedar escrita. De lo contrario, quien lea el análisis podría creer que también se evaluaron.

2.2. Fase 2: identificar y valorar los activos

Un activo es cualquier elemento que tenga valor para la organización o sea necesario para que un proceso funcione. No se limita al hardware: puede incluir información, aplicaciones, servicios, instalaciones, personas con conocimientos clave, procesos y dependencias de terceros.

Para cada activo relevante, registra información suficiente para entender su función y su importancia:

  • nombre, descripción y ubicación o responsable técnico;
  • proceso o servicio al que da soporte;
  • responsable de negocio o de la información;
  • datos que procesa y necesidades de confidencialidad, integridad y disponibilidad;
  • sistemas, proveedores y otros activos de los que depende.

No es necesario inventariar cada elemento con el mismo nivel de detalle. Un inventario inicial puede mantenerse en una hoja de cálculo; lo importante es que permita reconocer los activos que importan para el alcance y pueda revisarse cuando cambie la organización.

Activo Proceso relacionado Dependencias Necesidad destacada
ERP de pedidos Preparación y envío de pedidos Servidores, red, proveedor de soporte Disponibilidad e integridad de los pedidos
Datos de clientes Venta y atención posventa Base de datos, ERP, copias Confidencialidad e integridad
Servicio de copias Recuperación ante pérdida o cifrado Almacenamiento, credenciales, personal técnico Integridad y disponibilidad de las copias

El valor de un activo no equivale necesariamente a su precio de compra. Un servidor relativamente barato puede sostener un proceso crítico; una base de datos puede tener valor por la información que contiene, por las obligaciones aplicables y por el efecto que tendría perderla o divulgarla.

3. Fases 3 y 4: identificar amenazas, vulnerabilidades y salvaguardas

3.1. Fase 3: identificar amenazas y describir escenarios

Las amenazas pueden tener origen natural o ambiental, humano o técnico. Algunos ejemplos son un incendio, una inundación, un error de una persona usuaria, un error de administración, un ataque deliberado o una avería física o lógica.

No todas las amenazas afectan a todos los activos. Para seleccionar las relevantes, considera el entorno, los incidentes anteriores, la exposición del activo, sus dependencias y las consecuencias para el proceso. Los catálogos —por ejemplo, el catálogo de elementos de MAGERIT v3— sirven como punto de partida, no como lista que haya que aplicar íntegramente.

Una manera útil de concretar una amenaza es describir un escenario de riesgo: qué puede ocurrir, a qué activo o proceso afecta, qué condiciones lo facilitan y cuáles serían sus consecuencias. Si se estudia la destrucción o indisponibilidad de un servidor de ficheros, puede ser razonable considerar averías, daños por agua —por ejemplo, una fuga en una tubería— o fuego. Un impacto causado por un meteorito sería muy poco útil como escenario de trabajo ordinario: no porque sea imposible, sino porque apenas ayuda a tomar decisiones proporcionadas frente a las amenazas plausibles.

3.2. Fase 4: identificar vulnerabilidades

Una vulnerabilidad es una debilidad técnica, física, organizativa o humana que puede contribuir a que un escenario se materialice o agravar sus consecuencias. Algunos ejemplos son equipos sin soporte del fabricante, sistemas sin actualizar, permisos excesivos, procedimientos inexistentes o falta de mantenimiento de la climatización de un CPD.

La identificación puede combinar revisión de configuraciones y documentación, entrevistas, observación de procesos, auditorías y pruebas técnicas autorizadas. Un escáner puede detectar determinados problemas técnicos, pero no revela por sí solo si el procedimiento se cumple, si hay una dependencia crítica de un proveedor o si el personal sabe cómo actuar.

3.3. Fase 4 (continuación): revisar salvaguardas existentes

Las salvaguardas o controles son las medidas que la organización ya ha implantado o tiene previsto aplicar. Pueden ser preventivas, de detección o de recuperación; por ejemplo, controles de acceso, registros de actividad, un SAI, un grupo electrógeno, sistemas redundantes o copias de seguridad.

Hay que documentar si una medida existe, cuál es su alcance y qué evidencias muestran que funciona. Una copia programada no demuestra por sí sola que los datos se puedan restaurar: es necesario comprobarlo. Un SAI puede mantener el suministro durante un periodo limitado y facilitar una parada ordenada; un grupo electrógeno puede prolongarlo si está disponible, dimensionado y mantenido. Ninguno elimina todos los escenarios de interrupción eléctrica.

Las vulnerabilidades y las salvaguardas se incorporan a la estimación de probabilidad e impacto según el método elegido. No se deben sumar penalizaciones arbitrarias: una vulnerabilidad puede aumentar la probabilidad, las consecuencias o ambas, según el escenario; una salvaguarda puede reducir una o las dos dimensiones.

Ejemplo: servidor y condiciones ambientales

Si la climatización del CPD no recibe el mantenimiento recomendado, aumenta la posibilidad de que se den condiciones inadecuadas de temperatura. La falta de mantenimiento influye principalmente en la probabilidad de ese escenario; el impacto depende de qué servicios se interrumpirían, durante cuánto tiempo y de las alternativas de recuperación. Si hay redundancia adecuada y probada, puede reducirse el impacto de la caída de un servidor, aunque no desaparece la posibilidad de que ese servidor falle.

4. Fase 5: estimar y evaluar el riesgo

Una vez definidos el alcance y los escenarios, se estima para cada uno:

  1. la probabilidad o posibilidad de que ocurra, dentro de un periodo definido;
  2. el impacto que tendría sobre los objetivos, los servicios y la información;
  3. el nivel de riesgo resultante y si requiere tratamiento según los criterios acordados.

El impacto puede incluir interrupción del servicio, costes de recuperación, pérdida o alteración de datos, exposición de información, consecuencias contractuales o legales y daño reputacional. La importancia de cada dimensión depende del proceso y de la organización; una valoración técnica debe traducirse también a consecuencias que puedan entender las personas responsables del negocio.

4.1. Enfoques y escalas

La organización elige una metodología y define cómo interpretar sus resultados. Hay tres enfoques que conviene distinguir:

Enfoque Cómo expresa el resultado Precaución
Cualitativo Categorías descriptivas, como baja, media, alta o muy alta. Las categorías necesitan criterios compartidos; no basta con asignarlas por intuición.
Semicuantitativo Puntuaciones numéricas asignadas a escalas, por ejemplo de 1 a 5. El resultado es un índice para ordenar o comparar escenarios, no una medida exacta de pérdidas.
Cuantitativo Magnitudes medibles, como frecuencia estimada y pérdidas económicas. Requiere datos, supuestos y un método adecuados; mostrar decimales no hace que una estimación sea exacta.

En un análisis cualitativo se pueden definir, por ejemplo, probabilidad baja, media o alta atendiendo a la exposición, los antecedentes y las condiciones observadas. El impacto puede clasificarse por la duración de la interrupción, el volumen o sensibilidad de los datos afectados y las consecuencias económicas, operativas, legales o reputacionales. Las escalas deben documentarse para que dos personas puedan entender por qué se asignó cada nivel.

Una regla simplificada expresa la relación como riesgo ≈ probabilidad × impacto. Si se usan puntuaciones de 1 a 5, el producto es un índice semicuantitativo: no equivale automáticamente a una probabilidad real ni a un importe económico. En una estimación cuantitativa pueden combinarse una frecuencia estimada por periodo y una pérdida asociada, si los datos y los supuestos justifican el cálculo. La forma exacta de calcular el riesgo depende de la metodología.

4.2. Usar una matriz de riesgo

Una matriz cruza la probabilidad estimada con el impacto. La siguiente es solo una matriz didáctica de ejemplo: cada organización debe acordar sus criterios, umbrales y acciones. No es una escala oficial ni universal.

Impacto Probabilidad Baja Media Alta
Bajo Bajo Bajo Medio
Medio Bajo Medio Alto
Alto Medio Alto Muy alto
Muy alto Medio Alto Muy alto

Si el resultado supera el nivel que la organización considera aceptable, se propone un tratamiento o se eleva la decisión a la persona responsable del riesgo. El umbral puede expresarse como una categoría —por ejemplo, «tratar los riesgos altos y muy altos»— o mediante los valores de una escala numérica definida. No se debe copiar un umbral de otro análisis sin comprobar que tiene sentido para este contexto.

La matriz no toma decisiones por la organización

La matriz facilita una comparación, pero no convierte una estimación subjetiva en una verdad matemática. Hay que explicar los criterios, los datos y las incertidumbres, y dejar constancia de quién aprueba los umbrales y quién es responsable de cada riesgo.

4.3. Riesgo inicial y riesgo residual

Para que la valoración sea comprensible, puede distinguirse entre el riesgo sin considerar los controles actuales —a menudo llamado inherente— y el riesgo que permanece después de tener en cuenta las salvaguardas existentes —riesgo actual o residual, según el método utilizado—. Tras implantar un tratamiento, se vuelve a estimar el riesgo para comprobar qué nivel queda.

Por ejemplo, la caída del servidor principal podría detener un proceso importante. Una solución de alta disponibilidad bien configurada y probada puede reducir el impacto de esa caída. Sin embargo, no debe darse por eficaz por el mero hecho de que exista: hay que comprobar dependencias, capacidad, conmutación y recuperación. Del mismo modo, una vulnerabilidad identificada no permite subir automáticamente el impacto: debe razonarse qué dimensión del escenario modifica.

5. Fase 6: tratar el riesgo y conectar los resultados con el PDS

Cuando un riesgo requiere respuesta, la organización puede elegir entre cuatro estrategias generales. Los nombres concretos varían según el marco, pero las decisiones fundamentales son estas:

Estrategia Qué implica Ejemplo
Evitar Dejar de realizar la actividad que origina el riesgo, cuando sea viable. Retirar una Wi-Fi de cortesía que no sea necesaria y que resulte desproporcionado proteger.
Mitigar o modificar Implantar controles para reducir la probabilidad, el impacto o ambos. Disponer de una conexión a Internet de respaldo para mantener el acceso a servicios en la nube.
Compartir o transferir parte del riesgo Repartir determinadas consecuencias mediante acuerdos, servicios o seguros, sin suponer que el riesgo desaparece. Contratar un ciberseguro tras revisar sus límites, condiciones y exclusiones.
Aceptar o retener Mantener el riesgo de manera consciente, documentada y aprobada por quien tenga autoridad. Aplazar un grupo electrógeno por su coste, justificando la decisión y fijando una revisión.

La respuesta debe ser proporcional al contexto. Contratar un seguro puede cubrir ciertas pérdidas económicas, pero no evita el incidente ni elimina automáticamente el daño reputacional, las obligaciones legales o las responsabilidades de la organización. Externalizar un servicio tampoco hace desaparecer todos los riesgos: hay que valorar las dependencias y responsabilidades compartidas.

Tras elegir una opción, se define un plan de tratamiento que indique el escenario afectado, la decisión adoptada, las medidas, la persona responsable, los recursos y el plazo. Después se evalúa el riesgo residual y se registra si queda dentro del nivel aceptado. La aceptación no debería ser una decisión técnica unilateral: corresponde a la persona o función con autoridad y conocimiento del impacto para el negocio.

En el PDS, las medidas que requieren trabajo coordinado se convierten en iniciativas con prioridad, responsable, coste, calendario y evidencia de resultado. Así, el análisis no se queda en una tabla: alimenta decisiones y actuaciones concretas. Puede usarse también de forma aislada, siempre que se documenten el alcance, las decisiones y el seguimiento.

6. Ejemplo integrado: una editorial con tienda en línea

Retomemos la editorial con tienda en línea del tema sobre el Plan Director de Seguridad. Gestiona pedidos y almacén mediante un ERP. Sus copias se ejecutan semanalmente, pero todavía no se ha comprobado si permiten recuperar el servicio.

Elemento del análisis Decisión o dato del ejemplo
Alcance Tienda, ERP, datos y proceso de pedidos, copias y dependencias relevantes. Se documentan las exclusiones.
Activos ERP, pedidos, datos de clientes, servicio de copias y disponibilidad del proceso logístico.
Escenario Un ataque de ransomware cifra el ERP y deja sin acceso a pedidos y datos necesarios para prepararlos.
Debilidades que se deben comprobar Estado de actualizaciones, protección de cuentas, segmentación, protección de copias y capacidad real de restauración. No se presuponen sin evidencia.
Salvaguardas que se deben verificar Controles de acceso, registros, copias separadas y protegidas, y procedimientos de recuperación.
Valoración inicial Se estima la probabilidad según la exposición y la evidencia disponible, y el impacto según la interrupción, los datos afectados y las consecuencias para la organización. Las categorías son ilustrativas, no un resultado universal.
Tratamiento posible Mejorar controles de acceso y actualización, limitar la propagación, proteger las copias y realizar una restauración de prueba.
Seguimiento Asignar responsable y plazo, conservar evidencias de la prueba y volver a estimar el riesgo residual para decidir si es aceptable.

El análisis no debería concluir «el riesgo es alto» sin indicar por qué. Por ejemplo, puede justificarse un impacto alto si la interrupción paraliza los pedidos y la recuperación no está probada; la probabilidad necesita su propia justificación, basada en exposición, vulnerabilidades, antecedentes y controles. Si estos datos no se conocen, se anotan como incertidumbre y se solicita evidencia antes de presentar una puntuación como concluyente.

El tratamiento podría convertirse en varias iniciativas del PDS: probar la restauración de las copias, revisar las cuentas privilegiadas y preparar medidas para recuperar los procesos prioritarios. Tras implantarlas, hay que verificar que funcionan y recalcular el riesgo; no basta con marcar las tareas como completadas.

7. Buenas prácticas

Para realizar un análisis de riesgos útil y defendible:

  • Delimita y documenta el alcance: indica qué se incluye, qué se excluye y de qué dependencias se parte.
  • Relaciona los activos con los procesos: pregunta qué servicio o decisión se vería afectado si el activo falla, se altera o se expone.
  • Describe escenarios concretos: vincula una amenaza con activos, condiciones y consecuencias plausibles; evita listas genéricas sin contexto.
  • Apóyate en evidencias y consulta a las áreas implicadas: contrasta el inventario y las salvaguardas con las personas que conocen los procesos y los sistemas.
  • Define las escalas antes de puntuar: acuerda periodo, criterios de probabilidad e impacto y umbrales para decidir qué requiere tratamiento.
  • Distingue estimaciones de mediciones: explica si la valoración es cualitativa, semicuantitativa o cuantitativa y registra sus supuestos.
  • Comprueba que las medidas funcionan: una herramienta o un procedimiento documentado no demuestra por sí solo que el control reduzca el riesgo.
  • Asigna responsables y revisa los resultados: registra la aceptación del riesgo residual y vuelve a analizarlo con la periodicidad acordada y si cambian los activos, las amenazas, los controles o el negocio.

8. Errores frecuentes

Error frecuente Por qué ocurre Cómo evitarlo
Intentar analizar toda la organización sin concretar el alcance. Se confunde amplitud con utilidad y se omiten dependencias. Delimita el estudio, registra exclusiones y amplíalo por etapas si es necesario.
Confundir amenaza, vulnerabilidad, riesgo e incidente. Son conceptos relacionados y a veces se usan como sinónimos. Distingue el suceso posible, la debilidad, la combinación con sus consecuencias y el suceso ya materializado.
Asignar puntuaciones sin criterios ni evidencias. Las etiquetas parecen sencillas, pero ocultan supuestos distintos. Define las escalas, explica la valoración y anota las incertidumbres.
Tratar el producto de escalas de 1 a 5 como una pérdida económica exacta. Se confunden puntuaciones ordinales con magnitudes medidas. Llama al resultado índice semicuantitativo y reserva las estimaciones económicas para métodos y datos adecuados.
Aplicar una penalización automática por cada vulnerabilidad. Se presupone que todas modifican de igual forma cualquier escenario. Analiza si la debilidad afecta a la probabilidad, al impacto o a ambos, y justifica el cambio.
Dar por eficaz una salvaguarda porque figura en el inventario. Se confunde existencia con funcionamiento y cobertura. Busca evidencias: por ejemplo, prueba las restauraciones y la conmutación de sistemas redundantes.
Analizar amenazas improbables sin considerar el contexto. Se confunde posibilidad teórica con una prioridad práctica. Usa catálogos como orientación y selecciona escenarios pertinentes para el alcance.
Aceptar o transferir un riesgo como si desapareciera. Se confunde una decisión, un seguro o un contrato con la eliminación del escenario. Documenta qué consecuencias permanecen, quién acepta el riesgo y cuándo se revisará.
Considerar terminado el trabajo al completar la matriz. La valoración no se conecta con decisiones ni responsables. Vincula cada riesgo que lo requiera a un tratamiento, un responsable y una revisión del riesgo residual.

9. Resumen

En este tema has aprendido que:

  • el análisis de riesgos ayuda a tomar decisiones preventivas y a priorizar mejoras del PDS;
  • el trabajo parte de un alcance y relaciona activos con amenazas, vulnerabilidades, salvaguardas y consecuencias;
  • el riesgo se estima con criterios de probabilidad e impacto definidos para el contexto; una fórmula o matriz no convierte por sí sola la estimación en una medida exacta;
  • las decisiones de tratamiento son evitar, mitigar, compartir o transferir parte del riesgo, y aceptar o retenerlo de forma justificada;
  • después del tratamiento se evalúa el riesgo residual, se asignan responsables y se revisa el análisis cuando cambian las condiciones.

Idea clave

Un análisis de riesgos sirve para decidir con criterio qué proteger, qué mejorar y qué puede aceptarse. Su calidad depende del contexto, de las evidencias y de que las decisiones se traduzcan en medidas verificables.

10. Para seguir practicando

Continúa el caso de la editorial con tienda en línea:

  1. Define el alcance y anota al menos una exclusión justificada.
  2. Identifica cuatro activos y relaciónalos con el proceso de pedidos.
  3. Describe dos escenarios de riesgo distintos e indica qué evidencias necesitarías para valorar su probabilidad e impacto.
  4. Registra las vulnerabilidades y salvaguardas que confirmarías antes de asignar una categoría.
  5. Propón un tratamiento para el escenario que consideres prioritario, asigna un responsable y especifica cómo comprobarías el resultado.
  6. Revisa la plantilla de análisis de riesgos del PDS y compara sus campos con los pasos del tema. No habilites macros salvo que el profesorado lo indique y confíes en el origen del archivo.

Bibliografía y fuentes

Presentación