# Cyber Academy. Full content dump (Español) > GRC & cybersecurity certification training. Led by Christophe Mazzola (a practicing CISO) alongside a small team of practitioners. > Canonical URL: https://cyberacademy.net/es/ > Author: Christophe Mazzola (https://cyberacademy.net/es/christophe) > Index: https://cyberacademy.net/es/llms.txt > Other languages: https://cyberacademy.net/llms-full.txt | https://cyberacademy.net/fr/llms-full.txt | https://cyberacademy.net/es/llms-full.txt | https://cyberacademy.net/it/llms-full.txt | https://cyberacademy.net/de/llms-full.txt | https://cyberacademy.net/pt/llms-full.txt === # PILLAR PAGES # NIS 2: la guía que reemplaza tu vigilancia legal. **URL:** https://cyberacademy.net/es/resources/pillars/nis-2 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition NIS 2 (Directiva (UE) 2022/2555) es la directiva de la UE que hace responsables a los consejos de administración en materia de ciberseguridad. Las entidades medianas o grandes de 18 sectores enumerados están dentro del ámbito de aplicación. Ante un incidente significativo: alerta temprana en 24 horas, notificación en 72 horas, informe completo en un mes. Sanciones de hasta 10 millones de euros o el 2% del volumen de negocios mundial para las entidades esenciales. Transpuesta de forma desigual entre los Estados miembros desde octubre de 2024. ## TL;DR - Dentro del ámbito: 18 sectores, entidades medianas (50+ empleados / 10M+ de volumen de negocios) y mayores. Dos categorías, esenciales e importantes, con distinta intensidad de supervisión. - Diez medidas de gestión de riesgos de ciberseguridad bajo el Article 21. La directiva dice qué; ISO 27001 es el cómo más habitual. - Notificación de incidentes: alerta temprana en 24 horas, notificación en 72 horas, informe completo en un mes. Define el procedimiento antes de necesitarlo. - La responsabilidad personal y la rendición de cuentas de la dirección son ahora explícitas. El consejo es responsable, no solo el CISO. - El estado de la transposición varía de un país a otro; consulta a tu autoridad nacional antes de asumir que el texto de la UE se aplica tal cual. ## Full content ## Determinar si estás dentro del ámbito y en qué categoría El ámbito es la pregunta que decide todo lo demás, así que resuélvela primero y deja por escrito el razonamiento. NIS 2 se aplica a las entidades que operan en uno de los 18 sectores enumerados y que además cumplen un umbral de tamaño. La regla por defecto es el límite de la mediana empresa: al menos 50 empleados, o un volumen de negocios anual y un balance superiores a 10 millones de euros. Por debajo de ese límite, normalmente quedas fuera, pero no siempre: la directiva incluye a determinados proveedores independientemente de su tamaño cuando el servicio es lo suficientemente crítico (por ejemplo, proveedores de DNS, registros de dominios de nivel superior y algunos proveedores de comunicaciones electrónicas públicas y de servicios de confianza). Las dos categorías, esenciales e importantes, no son dos listas entre las que elegir. Se derivan de tu sector y tu tamaño. Los sectores de alta criticidad (energía, transporte, banca, infraestructura de los mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, administración pública, espacio) producen entidades esenciales en los tamaños mayores; los demás sectores enumerados, y las entidades más pequeñas dentro de los de alta criticidad, se clasifican generalmente como importantes. La consecuencia práctica es la intensidad de la supervisión, no un conjunto de obligaciones más laxo: las medidas de seguridad y los plazos de notificación son los mismos para ambas categorías. > **Haz la prueba de ámbito sobre el papel, y luego consérvala** El fallo habitual es tratar la pregunta "¿estamos dentro del ámbito?" como una conversación de pasillo. Realiza la prueba de forma explícita: sector, tamaño y cualquier desencadenante independiente del tamaño, con las cifras que alimentaron cada respuesta. Una autoridad nacional que discrepe preguntará cómo llegaste a la conclusión de que estabas fuera, y "no pensábamos que se aplicaba" no es una posición defendible cuando la responsabilidad recae en la dirección. ## Esenciales frente a importantes: dónde divergen realmente las dos categorías Ambas categorías llevan las mismas medidas del Article 21 y el mismo reloj de notificación de incidentes. Lo que cambia es cómo te vigila el regulador y qué puede hacer cuando algo va mal. Las entidades esenciales se enfrentan a una supervisión proactiva, ex ante: una autoridad puede inspeccionar y exigir pruebas sin esperar a que se produzca un incidente. Las entidades importantes se supervisan de forma reactiva, ex post, lo que significa que el escrutinio suele seguir a un incidente o a una denuncia creíble. Los topes de las sanciones también difieren, y esa brecha es la razón más citada para confirmar tu categoría pronto. **Supervisión y sanciones de NIS 2 por categoría de entidad** | Dimensión | Entidades esenciales | Entidades importantes | | --- | --- | --- | | Modelo de supervisión | Proactiva (ex ante): inspecciones y solicitudes de pruebas en cualquier momento | Reactiva (ex post): activada por un incidente o una denuncia | | Multa administrativa máxima | Al menos 10 millones de euros o el 2% del volumen de negocios anual mundial total, lo que sea mayor | Al menos 7 millones de euros o el 1,4% del volumen de negocios anual mundial total, lo que sea mayor | | Obligaciones de seguridad (Article 21) | Se aplican las diez medidas | Se aplican las diez medidas (idénticas) | | Plazo de notificación | 24h / 72h / 1 mes (idéntico) | 24h / 72h / 1 mes (idéntico) | | Rendición de cuentas de la dirección | Explícita; los órganos pueden ser considerados responsables, las personas pueden enfrentarse a prohibiciones temporales de dirección | Explícita; se aplica la responsabilidad individual, las prohibiciones de dirección se reservan generalmente para las entidades esenciales | Lee la tabla como lo hará un auditor: las medidas y los plazos son innegociables para todos, así que la categoría te dice sobre todo cuánto margen de error tienes antes de que alguien venga a investigar. Las entidades esenciales deben asumir que una inspección puede ocurrir en un tranquilo martes. Las entidades importantes deben asumir que la primera prueba real será un incidente en directo, que es el peor momento para descubrir que tus pruebas son escasas. ## Las diez medidas del Article 21, y por qué ISO 27001 es la respuesta habitual El Article 21(2) enumera diez categorías de medidas de gestión de riesgos de ciberseguridad que toda entidad dentro del ámbito debe implementar, de forma proporcionada a su exposición al riesgo. La directiva describe resultados, no controles, lo cual es deliberado: te dice qué debe cubrirse y deja el cómo en tus manos. 1. Políticas de análisis de riesgos y seguridad de los sistemas de información. 1. Gestión de incidentes (detección, respuesta y las obligaciones de notificación que se indican a continuación). 1. Continuidad de negocio, incluida la gestión de copias de seguridad y la recuperación ante desastres, y gestión de crisis. 1. Seguridad de la cadena de suministro, que cubre la seguridad de las relaciones con los proveedores directos y los prestadores de servicios. 1. Seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluida la gestión y la divulgación de vulnerabilidades. 1. Políticas y procedimientos para evaluar la eficacia de las medidas. 1. Prácticas básicas de higiene cibernética y formación en seguridad. 1. Políticas y procedimientos de criptografía y, cuando proceda, cifrado. 1. Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos. 1. Autenticación multifactor, comunicaciones seguras y comunicación de emergencia segura cuando proceda. Lee esa lista junto a un conjunto de controles del Annex A y el solapamiento es evidente. Por eso, en la práctica, la vía más común hacia un cumplimiento demostrable es un sistema de gestión de seguridad de la información ISO 27001. NIS 2 nombra los resultados; ISO 27001 te da el sistema de gestión, la disciplina de tratamiento de riesgos y las pruebas documentadas que se corresponden con nueve de las diez categorías sin mucha traducción. Estrictamente no necesitas un certificado para satisfacer NIS 2, pero la estructura del ISMS es la forma más limpia de producir los registros que una autoridad espera. La forma más rápida de que un equipo interiorice tanto la obligación como la construcción es combinar la perspectiva regulatoria con la perspectiva de implementación: el curso NIS 2 Directive Lead Implementer para el programa en sí, y el curso ISO 27001 Lead Implementer para levantar el ISMS que soporta la mayor parte del peso del Article 21. > **Mapea una vez, mantén para siempre** Construye una única matriz de control a requisito que alinee tu Declaración de Aplicabilidad de ISO 27001 con las diez categorías del Article 21. Cuando una autoridad nacional pregunte cómo cubres la seguridad de la cadena de suministro o la criptografía, señalas una fila en lugar de reconstruir el argumento bajo presión. Mantenla como un documento vivo, no como un ejercicio de mapeo puntual. ## El reloj de notificación: 24 horas, 72 horas, un mes La obligación de notificación se activa ante un incidente significativo, es decir, uno que ha causado o es capaz de causar una perturbación operativa grave o una pérdida financiera, o que ha afectado a terceros mediante daños materiales o inmateriales considerables. El reloj corre entonces en tres etapas hacia tu CSIRT nacional o autoridad competente. - 24 horas: una alerta temprana. Indica si sospechas que el incidente es ilícito o malintencionado y si podría tener impacto transfronterizo. Esto es un aviso, no un informe forense. - 72 horas: una notificación de incidente. Actualiza la alerta temprana con una evaluación inicial, que incluya gravedad, impacto y cualquier indicador de compromiso que tengas. - Un mes: un informe final. Un relato completo del incidente, su probable causa raíz, la mitigación aplicada y cualquier impacto transfronterizo. Si el incidente sigue en curso al cabo de un mes, proporcionas un informe de progreso y uno final cuando se cierre. Los plazos parecen generosos hasta que los contrastas con un incidente real. La alerta de 24 horas llega mientras todavía estás confirmando lo que ocurrió, así que el procedimiento debe estar definido de antemano: quién decide que un incidente es "significativo", quién redacta la alerta temprana, quién tiene la autoridad para presentarla y a qué portal o contacto va en cada Estado miembro donde operas. Ensáyalo. Un ejercicio de simulación que termine con una alerta temprana redactada contra el reloj vale más que cualquier documento de política sobre notificación. ## Responsabilidad de la dirección y los errores que aparecen en la sala de auditoría NIS 2 eleva la rendición de cuentas. Los órganos de dirección deben aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su implementación y recibir formación para poder identificar los riesgos ellos mismos. El incumplimiento puede atribuirse a personas concretas, y para las entidades esenciales las autoridades pueden imponer prohibiciones temporales a las personas que ejercen funciones de dirección. El consejo es responsable, y "el CISO se encarga de la seguridad" ya no es una respuesta completa ante un regulador. Los fallos recurrentes que vemos rara vez son exóticos. Son predecibles, y son evitables: - Tratar la transposición como uniforme. La directiva se transpone a la legislación nacional, y los plazos, los umbrales, los deberes de registro y los portales de notificación varían de un país a otro. Consulta a la autoridad nacional de cada Estado miembro donde operas antes de asumir que el texto de la UE se aplica tal cual. - Ignorar el deber de registro y autoidentificación. Muchos Estados miembros exigen que las entidades dentro del ámbito se registren ante la autoridad competente. Estar dentro del ámbito y sin registrar es por sí mismo una constatación, separada de cualquier brecha de seguridad. - Invertir poco en la seguridad de la cadena de suministro. Es una de las diez medidas, y es donde las entidades más grandes están más expuestas. Un proceso débil de riesgo de proveedores es una debilidad visible. - Confundir categorías con obligaciones. Las entidades importantes a veces asumen que una supervisión más ligera significa deberes más ligeros. No es así: se aplican las mismas medidas y el mismo reloj de notificación. - Ningún procedimiento de notificación ensayado. La alerta de 24 horas es la obligación que más a menudo se incumple, porque nadie asumió la decisión ni el borrador hasta que el incidente lo forzó. Si tu equipo necesita orientarse sobre el ámbito, las categorías y las obligaciones antes de comprometerse con una construcción, el curso NIS 2 Directive Foundation es el punto de partida adecuado; pasa a los itinerarios Lead Implementer e ISO 27001 una vez que estés definiendo el alcance del programa en sí. NIS 2 interactúa con otros regímenes de la UE (DORA gobierna la resiliencia operativa del sector financiero y generalmente prevalece allí como la regla más específica; la Ley de IA añade sus propias obligaciones para los sistemas de IA), así que confirma qué régimen es el principal para una obligación dada en lugar de notificar el mismo incidente dos veces o, peor, no notificarlo en absoluto. En caso de duda, la postura segura es la que la propia directiva recompensa: decisiones documentadas, una correspondencia de controles mantenida y un procedimiento de notificación que hayas ensayado antes de necesitarlo. ## FAQ ### ¿Estoy dentro del ámbito de aplicación de NIS 2? Dos filtros: sector y tamaño. Debes estar en uno de los 18 sectores enumerados (energía, transporte, finanzas, salud, infraestructura digital, administración pública, espacio, alimentación, productos químicos, servicios postales, fabricación de productos críticos, investigación, gestión de residuos, además de algunos otros). Y debes cumplir el umbral de tamaño: 50+ empleados o 10 millones de euros de volumen de negocios anual. Por debajo de eso, quedas fuera del ámbito por defecto, con excepciones nacionales para entidades críticas de cualquier tamaño. Dos categorías dentro del ámbito: las entidades esenciales (energía, transporte, banca, infraestructura de los mercados financieros, salud, agua potable, aguas residuales, infraestructura digital, gestión de servicios de TIC B2B, administración pública, espacio) se enfrentan a una supervisión más estricta y a sanciones más altas. Las entidades importantes (postal, residuos, productos químicos, alimentación, fabricación, proveedores digitales, investigación) se enfrentan a una supervisión más ligera pero a las mismas obligaciones de control. ### ¿Cuáles son las diez medidas del Article 21? El Article 21(2) enumera diez medidas de gestión de riesgos de ciberseguridad: (a) políticas de análisis de riesgos y seguridad de los sistemas de información; (b) gestión de incidentes; (c) continuidad de negocio y gestión de crisis; (d) seguridad de la cadena de suministro; (e) seguridad en la adquisición, el desarrollo y el mantenimiento; (f) políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad; (g) higiene cibernética básica y formación en ciberseguridad; (h) políticas de criptografía y cifrado; (i) seguridad de los recursos humanos, control de acceso y gestión de activos; (j) el uso de autenticación multifactor, comunicaciones de voz/vídeo/texto seguras y sistemas de comunicación de emergencia seguros. La directiva no dice cómo implementar cada una. ISO 27001 se corresponde con claridad con las diez; NIST CSF y CIS Controls cubren la mayoría de ellas. Elige un marco, documenta la correspondencia y la autoridad de supervisión quedará satisfecha. ### ¿Cuál es el plazo de notificación de incidentes? Ante un incidente significativo, tres plazos: alerta temprana en 24 horas (evaluación inicial, si se sospecha que el incidente ha sido causado por actos ilícitos o malintencionados, posible impacto transfronterizo); notificación en 72 horas (evaluación más amplia, indicadores de compromiso); informe final en un mes (descripción detallada del incidente, gravedad, impacto, medidas de mitigación adoptadas, análisis de la causa raíz cuando esté disponible). Un incidente significativo es aquel que ha causado o es capaz de causar una perturbación operativa grave o pérdidas financieras, o que afecta a terceros causando daños materiales o inmateriales considerables. Los umbrales son aclarados por las autoridades nacionales; consulta los tuyos. ### ¿Cuáles son las sanciones? Las entidades esenciales se enfrentan a multas administrativas de hasta 10 millones de euros o el 2% del volumen de negocios anual mundial, lo que sea mayor. Las entidades importantes se enfrentan a hasta 7 millones de euros o el 1,4% del volumen de negocios anual mundial. Las autoridades nacionales también pueden imponer sanciones no financieras: órdenes de cumplimiento, divulgación pública del incumplimiento, prohibiciones temporales a las personas de la dirección de ejercer su cargo. Las sanciones no son el único vector de aplicación. El diálogo de supervisión, las auditorías y las órdenes de ejecutar una acción correctiva específica se sitúan por debajo del umbral de la multa y son más habituales en la práctica. ### ¿Cómo interactúa NIS 2 con DORA y la Ley de IA? Para las entidades financieras, DORA es lex specialis en materia de TIC: cuando DORA se aplica, prevalece sobre NIS 2 en las disposiciones relacionadas con las TIC. Las entidades financieras siguen aplicando NIS 2 para los temas no relacionados con las TIC cubiertos por la directiva. La Ley de IA es paralela: regula los sistemas de IA, no los programas de ciberseguridad. Si operas sistemas de IA de alto riesgo dentro de un sector crítico, te enfrentas a ambas: NIS 2 para la línea de base de ciberseguridad, la Ley de IA para el trabajo de conformidad de la IA. ## Official sources - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [ENISA, NIS 2 hub](https://www.enisa.europa.eu/topics/cybersecurity-policy/nis-directive-new) - [ANSSI, Transposition NIS 2 (France)](https://cyber.gouv.fr/nis-2) --- # DORA: lo que su RSSI no le contó. **URL:** https://cyberacademy.net/es/resources/pillars/dora **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition DORA (Regulation (EU) 2022/2554) es el reglamento de la UE que impone un marco unificado de resiliencia operativa digital a las entidades financieras y a sus proveedores terceros críticos de TIC. Aplicable desde el 17 de enero de 2025. Cinco pilares: gestión del riesgo de TIC, notificación de incidentes, pruebas de resiliencia incluyendo pruebas de penetración basadas en amenazas, riesgo de terceros de TIC, intercambio de información. Lex specialis sobre NIS 2 en materias de TIC. ## TL;DR - Se aplica a unas 20 categorías de entidades financieras más los proveedores terceros críticos de TIC designados, desde el 17 de enero de 2025. - Cinco pilares. El registro de terceros (Pilar 4) y las pruebas de resiliencia (Pilar 3, incluyendo TLPT para las entidades significativas) son los más operativos y los más auditados. - Para las entidades significativas, pruebas de penetración basadas en amenazas cada tres años, supervisadas por la autoridad nacional conforme a TIBER-EU. - Los proveedores terceros críticos de TIC son supervisados directamente por las Autoridades Europeas de Supervisión (ESAs). Su riesgo de concentración ahora importa a nivel de la UE. - Combine con ISO 22301 para el BCMS, ISO 27001 para la gestión del riesgo de TIC, y Lead Operational Resilience Manager para la capa orientada al supervisor. ## Full content La mayoría de las entidades financieras no empezaron DORA desde cero. Tenían un ISMS, un plan de continuidad de negocio, una política de externalización, y un inventario de terceros que eran en su mayoría contratos de compras. DORA no descarta eso. Lo reformula, eleva el listón en dos pilares en particular, y desplaza la conversación de "¿tiene usted un control?" a "¿puede demostrar que su servicio sigue funcionando cuando un proveedor de TIC falla?". Esta página trata sobre esa brecha: cómo aterrizan realmente los cinco pilares en las operaciones, qué abre primero un supervisor, y dónde pierden tiempo los equipos. ## Los cinco pilares, y quién es auditado en cada uno El reglamento se construye sobre cinco pilares. No tienen el mismo peso en la práctica. El Pilar 1 es fundamental pero familiar para cualquiera que opere un ISMS. Los Pilares 3 y 4 son donde se concentra la atención supervisora, porque producen evidencia difícil de falsificar y fácil de poner a prueba. La tabla siguiente es la versión que utilizamos para informar a un consejo: qué exige cada pilar, y quién dentro de la entidad acaba más expuesto cuando el regulador pide pruebas. **Los cinco pilares de DORA: requisito y la función más auditada en cada uno** | Pilar | Qué exige | Más auditado en él | | --- | --- | --- | | 1. Gestión del riesgo de TIC | Un marco de gobernanza documentado: mapeo de activos y dependencias, identificación de riesgos, controles de protección y detección, respuesta y recuperación, con la propiedad del consejo y una función responsable designada. | CISO / RSSI y el órgano de dirección, que debe demostrar una supervisión activa, no delegación. | | 2. Gestión y notificación de incidentes de TIC | Clasificar los incidentes relacionados con las TIC según criterios armonizados, y luego notificar los incidentes graves a la autoridad competente en el calendario inicial / intermedio / final. | La respuesta a incidentes y el SOC, más quien sea responsable de las notificaciones regulatorias. | | 3. Pruebas de resiliencia operativa digital | Un programa de pruebas basado en el riesgo; para las entidades significativas, pruebas de penetración basadas en amenazas (TLPT) sobre sistemas de producción en vivo al menos cada tres años. | Las pruebas de seguridad, el red team, y los responsables de negocio de los sistemas incluidos en el alcance. | | 4. Riesgo de terceros de TIC | Un registro de todos los acuerdos con terceros de TIC, cláusulas contractuales sobre auditoría, salida y subcontratación, y análisis del riesgo de concentración. | Compras, gestión de proveedores y el área jurídica, que deben presentar el registro y los contratos cuando se les requiera. | | 5. Intercambio de información | Mecanismos voluntarios para intercambiar inteligencia sobre ciberamenazas entre entidades financieras. | La inteligencia de amenazas; el pilar más ligero y rara vez un hallazgo por sí solo. | ## Qué hacer primero El error es empezar por la actualización de políticas, porque ese es el trabajo cómodo. Empiece en cambio por los dos artefactos que un supervisor puede pedir por escrito y que más tardan en construirse correctamente: el registro de terceros de TIC y el mapeo de las funciones críticas o importantes a los activos y proveedores de TIC que las sustentan. Todo lo demás depende de ese mapeo. No puede delimitar el alcance de las pruebas de resiliencia, no puede clasificar la gravedad de los incidentes, y no puede razonar sobre el riesgo de concentración hasta que sepa qué funciones son críticas y de qué dependen. Una secuencia viable para los primeros 90 días: 1. Defina sus funciones críticas o importantes. Esta es una decisión de negocio, no de seguridad. Determina el alcance de casi todas las demás obligaciones. 1. Mapee cada función crítica a los servicios de TIC, internos y externalizados, de los que depende. Este es su grafo de dependencias. 1. Construya el registro de terceros a partir de ese grafo, no a partir de la hoja de cálculo de compras. El registro debe describir los acuerdos que sustentan funciones, incluidos los subcontratistas de la cadena. 1. Cierre primero las brechas contractuales que DORA exige (derechos de auditoría, estrategias de salida, transparencia de la subcontratación, cooperación en incidentes) sobre los acuerdos que sustentan funciones críticas. 1. Solo entonces formalice el marco de gestión del riesgo de TIC y el programa de pruebas, porque ambos tienen ya un alcance definido contra el cual trabajar. > **Secuencie el registro antes que las políticas** Si tiene capacidad limitada, el registro y el mapeo de funciones críticas son el trabajo portante. Desbloquean la clasificación de incidentes, el alcance de las pruebas y el análisis de concentración. Una política de riesgo de TIC bellamente redactada sin un mapa de dependencias debajo es lo primero que un examinador descubre. ## El registro de terceros de TIC (Pilar 4) en la práctica El registro no es una lista de proveedores. Es un conjunto estructurado de registros de información que la entidad mantiene y que las autoridades competentes recopilan, en una plantilla definida, para ver la concentración de TIC en todo el sector financiero. Eso cambia cómo se construye. Un campo que es "suficientemente bueno" para uso interno se convierte en un problema de calidad de datos cuando se agrega a nivel nacional y de la UE. Tres cosas causan la mayor parte del dolor. Primero, la unidad es el acuerdo contractual, no el proveedor. Un mismo proveedor puede situarse detrás de varios acuerdos, y un mismo acuerdo puede sustentar varias funciones. Está describiendo un grafo de muchos a muchos, y aplanarlo en una fila por proveedor no sobrevivirá a la revisión. Segundo, tiene que seguir la cadena. El registro debe capturar los subcontratistas que efectivamente sustentan una función crítica o importante, lo que significa que su visibilidad sobre el proveedor tiene que llegar más allá de su contraparte directa. Si su contrato no le da el derecho a saber quién es el cuarto tercero, esa es una brecha contractual que cerrar, no un campo que dejar en blanco. Tercero, el indicador de criticidad de función en cada acuerdo es el campo del que todo lo demás depende. Marque demasiado como crítico y ahogará sus propias pruebas y remediación contractual; marque demasiado poco y subestimará el riesgo de concentración y engañará al supervisor. Acierte la evaluación de criticidad una vez, a nivel de función, y deje que se propague. > **El riesgo de concentración es ahora una preocupación a nivel de la UE** Cuando un único proveedor de nube o de core bancario sustenta funciones críticas en muchas entidades, ese proveedor puede ser designado proveedor tercero crítico de TIC y supervisado directamente por las ESAs. Su registro es uno de los insumos que pone esto de manifiesto. Trate la calidad de los datos del registro como una exposición supervisora, no como una tarea administrativa. ## Pruebas de penetración basadas en amenazas (Pilar 3): cómo es realmente la sala El TLPT es el pilar que sorprende a la gente, porque no se parece a una prueba de penetración rutinaria. Está dirigido por inteligencia, se ejecuta contra sistemas de producción en vivo, está delimitado a las funciones críticas o importantes, y se realiza conforme a la metodología TIBER-EU con la autoridad nacional involucrada. Las entidades significativas lo ejecutan al menos en un ciclo de tres años. Está más cerca de un ejercicio de red team supervisado que de un escaneo de vulnerabilidades, y el entregable que importa no es la lista de hallazgos; es la evidencia de que la detección y la respuesta funcionaron, o el relato honesto de por qué no lo hicieron. Tres realidades que los equipos subestiman: - El alcance lo determinan las funciones críticas, no lo que es conveniente probar. Si una función abarca un proveedor externalizado, ese proveedor puede tener que estar dentro del alcance, lo que significa que la cooperación del proveedor tiene que asegurarse contractualmente por adelantado. - Por lo general no se avisa al blue team. El valor está en probar la detección y la respuesta reales, así que un TLPT del que se haya advertido a los defensores ha perdido la mayor parte de su sentido. Eso tiene consecuencias organizativas que se planifican, no se descubren a mitad del ejercicio. - Los probadores y los proveedores de inteligencia de amenazas deben cumplir requisitos de competencia e independencia, y la autoridad revisa el proceso. No puede simplemente reetiquetar el pentest anual del año pasado como TLPT. Si su entidad está por debajo del umbral de significatividad, no ejecutará TLPT, pero aun así debe un programa de pruebas basado en el riesgo: evaluaciones de vulnerabilidad, pruebas basadas en escenarios, y pruebas de resiliencia de la vía de recuperación. El curso Lead Operational Resilience Manager está construido en torno exactamente a esta capa de pruebas y evidencia orientada al supervisor, y el curso DORA Lead Manager cubre cómo se gobierna el programa completo de extremo a extremo. ## DORA como lex specialis sobre NIS 2 para los bancos Los bancos, y la mayoría de las demás entidades financieras, caen dentro del ámbito tanto de NIS 2 como de DORA. Los dos se solapan en gran medida en el riesgo de TIC, la notificación de incidentes y la seguridad de la cadena de suministro, lo que plantea el temor evidente de hacerlo todo dos veces. DORA lo resuelve: en las materias de TIC que rige, DORA es lex specialis. La norma específica desplaza a la general. Allí donde DORA establece la obligación de gestión del riesgo de TIC y de notificación de incidentes, una entidad financiera sigue DORA, y las autoridades competentes no deberían aplicar el requisito equivalente de NIS 2 por encima de ella para la misma materia de TIC. Lo que esto no significa: no desactiva por completo NIS 2 para una entidad financiera, y no cambia cuál es su autoridad competente para las materias no relacionadas con las TIC. La decisión práctica para un banco es mapear cada obligación a su instrumento rector: la resiliencia operativa de TIC, la notificación de incidentes y el riesgo de terceros de TIC se rigen por DORA; cualquier cosa fuera de DORA es un alcance que evalúa por separado. Documente ese mapeo. Es la respuesta a la pregunta de "¿está contando dos veces o de menos?" que tanto los examinadores como los auditores plantean. > **La lógica de lex specialis es una herramienta de decisión, no un resquicio legal** Úsela para evitar notificaciones duplicadas y calendarios contradictorios, no para argumentar la eliminación de una obligación. Si una materia de TIC se rige por DORA, cumple el estándar de DORA; no puede elegir cuál de los dos regímenes es menos exigente. ## Errores comunes y dónde construir la competencia Los fallos recurrentes no son exóticos. El registro se construye por proveedor en lugar de por acuerdo y se rompe en cuanto la subcontratación importa. La criticidad de las funciones críticas la evalúa el área de TI en lugar del negocio, de modo que el alcance de todo lo que viene después es erróneo. Los umbrales de clasificación de incidentes se redactan pero nunca se prueban contra un incidente real, de modo que el primer evento grave se convierte en el primer ensayo del calendario de notificación. Y la continuidad de negocio se trata como un proyecto ISO 22301 separado en lugar de como el músculo de recuperación que las pruebas de DORA están destinadas a ejercitar. Ese último punto importa: DORA no reemplaza un sistema de gestión de continuidad de negocio, lo presupone. Los objetivos de recuperación y la vía de recuperación probada que le da un BCMS son lo que las pruebas de resiliencia validan. Construya el BCMS correctamente con el curso ISO 22301 Lead Implementer, y se convierte en el sustrato sobre el que se apoyan las obligaciones de resiliencia operativa en lugar de un archivador paralelo que nadie abre. Si parte del reglamento en sí, el curso DORA Foundation da a todo el equipo una lectura compartida y exacta de los cinco pilares y del ámbito antes de que nadie toque el registro o el programa de pruebas. A partir de ahí, el curso DORA Lead Manager es la capa de implementación y gobernanza para las personas que serán propietarias del marco, y el curso Lead Operational Resilience Manager es para la función que tiene que presentarse ante el supervisor y demostrar que la resiliencia es real, no documentada. ## FAQ ### ¿Quién está dentro del ámbito de DORA? Alrededor de 20 categorías de entidades financieras: entidades de crédito, entidades de pago, entidades de dinero electrónico, empresas de inversión, entidades de contrapartida central, centros de negociación, depositarios centrales de valores, empresas de seguros y de reaseguros, intermediarios, proveedores de servicios de criptoactivos, proveedores de servicios de información sobre cuentas, gestores de fondos de inversión alternativos, sociedades de gestión, proveedores de servicios de suministro de datos, agencias de calificación crediticia, administradores de índices de referencia cruciales, proveedores de servicios de financiación participativa, registros de titulizaciones. Más un régimen separado para los proveedores terceros críticos de TIC (CTPPs) designados por las ESAs sobre la base de una evaluación de criticidad. Los CTPPs se enfrentan a una supervisión directa por un Foro de Supervisión Conjunto dirigido por una ESA. ### ¿Qué es el TLPT y quién lo necesita? El Threat-Led Penetration Testing es un ejercicio de red team supervisado por el regulador exigido a las entidades financieras significativas conforme a DORA. Construido sobre el marco TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). Cada tres años como mínimo. El TLPT está dirigido por inteligencia (perfil de amenaza elaborado por un equipo de inteligencia separado), se dirige a funciones críticas o importantes de la entidad, y es supervisado por la autoridad nacional. Dura varios meses, es costoso, y es la prueba más rigurosa a la que se enfrentará un CISO financiero. ### ¿Cómo interactúa DORA con NIS 2 para los bancos? DORA es lex specialis en materias de TIC. Allí donde DORA se aplica, prevalece sobre NIS 2 para las disposiciones relativas a las TIC. Para las materias de NIS 2 no relacionadas con las TIC (seguridad física, ciertos aspectos de gobernanza, alcance de la formación), NIS 2 sigue aplicándose en paralelo. En la práctica, un banco dentro del ámbito de ambos aplica DORA en su totalidad para el riesgo de TIC, la notificación de incidentes, las pruebas de resiliencia y el riesgo de terceros de TIC, mientras consulta NIS 2 para la línea de base de gobernanza de ciberseguridad restante. ### ¿Qué va en el registro de terceros de TIC? El Article 28 más las RTS de la EBA sobre subcontratación y sobre el registro de información especifican los campos. Cada acuerdo contractual con un proveedor de servicios de TIC se registra con: naturaleza de los servicios, criticidad, cadena de subcontratación visible para la entidad, ubicación de los servicios, ubicación de los datos, SLAs de rendimiento, estrategia de salida, mecanismos de gobernanza. El registro es el documento que la autoridad de supervisión pide primero. La mayoría de las entidades financieras subestiman la carga de mantenimiento; un registro desactualizado se trata como un hallazgo. ### ¿Cuál es la relación entre DORA e ISO 22301? DORA no exige la certificación ISO 22301 pero las obligaciones de BCM y de recuperación ante desastres del reglamento (Articles 11-12) se corresponden casi uno a uno con un BCMS conforme a ISO 22301. La mayoría de las entidades que ya operan un BCMS 22301 añaden la capa de pruebas y notificación específica de DORA sin reconstruir los cimientos. ## Official sources - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) - [European Banking Authority, DORA hub](https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act) - [ESMA, DORA implementation](https://www.esma.europa.eu/regulation/digital-operational-resilience) --- # ISO 27001: Foundation, Lead Implementer, Lead Auditor, ¿cuál elegir? **URL:** https://cyberacademy.net/es/resources/pillars/iso-27001-foundation-li-la **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 27001 tiene tres niveles de certificación: Foundation (2 días, vocabulario y estructura), Lead Implementer (5 días, construir el ISMS) y Lead Auditor (5 días, auditarlo). Foundation es el requisito previo para las credenciales sénior. Lead Implementer encaja con los equipos de seguridad y GRC que son responsables del ISMS; Lead Auditor encaja con los auditores internos y los profesionales de organismos de certificación. ## TL;DR - Foundation es el requisito previo. Aporta el vocabulario y el modelo mental del sistema de gestión. Dos días, examen de 1 hora. - Lead Implementer (5 días) le enseña a construir el ISMS, redactar la SoA, ejecutar el tratamiento del riesgo y operar el ciclo de revisión por la dirección. - Lead Auditor (5 días) le enseña a planificar y dirigir auditorías de tercera parte o internas. Una mentalidad distinta: evidencia, muestreo, técnica de entrevista, redacción de informes. - La mayoría de los CISO y responsables de seguridad cursan Lead Implementer. Los auditores internos y los consultores de las Big Four cursan Lead Auditor. Hacer ambos en un periodo de 12 a 18 meses es habitual. - Tasas de aprobación en cohortes PECB presenciales con instructor: 99,1% al primer intento en nuestra impartición; la media del mercado es del 80% al 85% según el partner. ## Full content ## La decisión que realmente importa: ¿está construyendo o auditando? Las tres credenciales de ISO 27001 no son una única escalera que se sube en orden. Foundation es la base compartida, pero por encima de ella el camino se bifurca en dos trabajos distintos. Un trabajo consiste en diseñar y operar un sistema de gestión de seguridad de la información (ISMS) dentro de una organización. El otro consiste en examinar el ISMS de otra persona frente a la norma y formar una opinión independiente. Los títulos lo señalan: Lead Implementer es un constructor, Lead Auditor es un examinador. Elegir el equivocado desperdicia una semana de formación y le da un certificado que no se corresponde con el trabajo que tiene delante. Hágase una pregunta antes de reservar nada: en los próximos doce meses, ¿será responsable de que un ISMS exista y funcione, o responsable de juzgar si funciona? Si es propietario de la Declaración de Aplicabilidad, del plan de tratamiento del riesgo y de la revisión por la dirección, está construyendo. Si entra, muestrea evidencia y redacta hallazgos, está auditando. El verbo que hace la mayoría de los días es toda la decisión. En cualquier caso, empieza en el mismo sitio. El curso ISO 27001 Foundation le aporta el vocabulario, la estructura de controles del Anexo A y la lógica del sistema de gestión que ambas vías sénior dan por supuesto que usted ya domina. ## Qué evalúa realmente cada examen (más allá del folleto) Las descripciones de los niveles le indican la duración. No le dicen qué recompensa la evaluación, que es lo que determina cómo debería prepararse. ### Foundation Foundation es un examen de conocimiento. Comprueba que puede leer la norma sin perderse: las cláusulas 4 a 10, el ciclo Plan-Do-Check-Act, la diferencia entre un control y un objetivo de control, y dónde se sitúa el Anexo A respecto a los requisitos principales. No le pide aplicar nada bajo presión. Si sabe explicar por qué la SoA debe justificar tanto las inclusiones como las exclusiones, está listo. ### Lead Implementer Lead Implementer es un examen de competencia construido en torno a escenarios. Se le da una organización ficticia y se le pregunta qué haría: cómo definiría el alcance del ISMS, cómo ejecutaría la evaluación de riesgos, qué entra en el plan de tratamiento del riesgo, cómo gestionaría un control no conforme. Las preguntas premian el criterio, no la memorización. El curso Lead Implementer se estructura en torno al proyecto de implementación completo, de modo que los escenarios del examen se sienten como un trabajo que ya ha hecho. ### Lead Auditor Lead Auditor pone a prueba un músculo distinto: la metodología de auditoría ISO 19011 aplicada a ISO 27001. Los escenarios le sitúan en la sala de auditoría. Decide qué evidencia prueba que una cláusula se cumple, cómo muestrear, cómo formular un hallazgo y cómo calificarlo como no conformidad mayor o menor. La trampa en la que caen los candidatos es auditar como implementarían, diciéndole al auditado cómo arreglar las cosas en lugar de declarar qué es no conforme. El curso Lead Auditor entrena la disciplina de evidencia primero, opinión y no consejo, que tanto el examen como las auditorías reales exigen. ## Los tres niveles, uno al lado del otro **Comparación de los niveles de certificación de ISO 27001** | | Foundation | Lead Implementer | Lead Auditor | | --- | --- | --- | --- | | Trabajo principal | Comprender la norma | Construir y operar el ISMS | Auditar un ISMS | | Rol típico | Cualquiera nuevo en ISO 27001 | CISO, responsable de seguridad, propietario de GRC | Auditor interno, auditor de organismo de certificación o de consultoría | | Duración | 2 días | 5 días | 5 días | | Estilo de examen | Conocimiento, examen corto | Basado en escenarios, criterio aplicado | Metodología de auditoría (ISO 19011), evidencia y hallazgos | | Entregable clave que puede producir después | Leer y navegar la norma | Alcance, SoA, plan de tratamiento del riesgo, revisión por la dirección | Plan de auditoría, programa de auditoría, informe de hallazgos | | Mentalidad | Vocabulario y estructura | Diseñar, operar, mejorar | Evidencia, muestreo, opinión independiente | | Requisito previo | Ninguno | Conocimiento de nivel Foundation | Conocimiento de nivel Foundation | ## Requisitos previos y qué le aporta realmente el siguiente paso Foundation es el requisito previo para las credenciales sénior, pero léalo con precisión: la mayoría de los esquemas de acreditación exigen conocimiento de nivel Foundation, no necesariamente un certificado Foundation independiente obtenido de antemano. En la práctica, los cursos sénior abren con un repaso comprimido de los fundamentos y luego los dan por supuestos. Si llega sin esa base, pasa el primer día poniéndose al día en lugar de aprender el método, y el trabajo de escenarios del resto de la semana cae sobre terreno poco firme. Cursar Foundation primero no es marcar una casilla burocrática; es lo que permite que el curso de cinco días enseñe con toda su profundidad. Lo que le aporta el siguiente paso es palanca, no solo una línea en el CV. Foundation le aporta la capacidad de participar en una conversación sobre el ISMS sin perderse. Lead Implementer le aporta la capacidad de ser responsable de que el sistema exista: puede definir su alcance, defender la SoA ante un auditor y operar el ciclo. Lead Auditor le aporta independencia: puede firmar hallazgos en los que un organismo de certificación o un consejo de administración confiarán. Son formas de autoridad genuinamente distintas, razón por la cual hacer ambas en un periodo de doce a dieciocho meses es habitual y útil. Un implementador que también se ha formado como auditor construye un ISMS que sobrevive a la auditoría, porque sabe qué buscará el auditor. > **Construir primero, auditar después (normalmente)** Si es propietario o lo será de un ISMS, curse primero Lead Implementer. Habiendo realizado la construcción, el curso de auditoría cobra sentido de inmediato porque sabe cómo se ve una buena evidencia. El orden inverso funciona para los auditores internos puros que nunca serán propietarios de un control, pero es el caso minoritario. Elija la vía que se corresponde con su trabajo diario, no la que suena más sénior. ## Errores comunes que cuestan una semana Algunos patrones aparecen repetidamente cuando se elige o se cursan estos cursos. Son evitables. 1. Tratar Lead Auditor como la versión de mayor estatus de Lead Implementer. No está por encima; está al lado. Reservarlo por prestigio cuando su trabajo es construir el ISMS le da una habilidad que rara vez usará. 1. Saltarse la base de Foundation para ahorrar dos días y luego perder más de dos días dentro del curso sénior poniéndose al día en vocabulario mientras todos los demás lo aplican. 1. Implementadores que auditan dando consejos, y auditores que auditan redactando planes de mejora. El auditor declara qué es no conforme y señala la cláusula; la corrección corresponde al auditado. Cruzar esa línea suspende los escenarios del examen y compromete las auditorías reales. 1. Confundir la norma con los controles. El Anexo A es un conjunto de referencia del que se selecciona a través de la SoA. Los requisitos certificables viven en las cláusulas 4 a 10. Los candidatos que memorizan controles pero no saben explicar las cláusulas del sistema de gestión tienen dificultades en ambos exámenes sénior. ## La realidad de la sala de auditoría, y por qué moldea ambas vías Para cualquiera de los dos lados para los que se forme, imagine la auditoría de certificación, porque es donde se encuentran los dos roles. El auditor pide evidencia de que una cláusula se satisface y de que un control seleccionado opera como la SoA afirma. El implementador tiene que producir esa evidencia a demanda: registros de la evaluación de riesgos, las decisiones de tratamiento, las actas de la revisión por la dirección, los resultados de la auditoría interna, las acciones correctivas. Nada impresiona a un auditor; solo la evidencia lo hace. Un control que existe pero no deja registro es, a efectos de auditoría, un control que no existe. Por eso los profesionales más fuertes comprenden ambas perspectivas incluso cuando solo hacen un trabajo. El implementador diseña el ISMS de modo que hacer el trabajo también cree el rastro. El auditor lee ese rastro sin que le cuenten una historia sobre él. Si está eligiendo su primer curso, elija el rol en el que vivirá y luego planifique el segundo curso para cuando quiera la otra mitad del cuadro. La norma es un único sistema visto desde dos sillas, y la credencial que elija debería corresponderse con la silla en la que se sienta. ## FAQ ### ¿Debería cursar primero Lead Implementer o Lead Auditor? Ajústelo a su rol. Si construye, opera o mantiene el ISMS (responsable de seguridad, analista de GRC, CISO de una organización más pequeña), primero Lead Implementer. El curso le enseña a redactar la SoA, ejecutar el tratamiento del riesgo, elaborar las políticas y operar la revisión por la dirección. Si audita (equipo de auditoría interna, consultor de las Big Four, auditor de organismo de certificación), primero Lead Auditor. El curso enseña el ciclo de auditoría, el muestreo de evidencia, la técnica de entrevista y la disciplina de redactar hallazgos. Hacer ambos es habitual. En ese caso, el orden importa poco; algunos profesionales van de LI a LA para adquirir la profundidad operativa antes de la mirada de auditoría, otros van de LA a LI para interiorizar qué buscan los auditores antes de construir. ### ¿De verdad se requiere Foundation? Sí, formalmente. PECB exige Foundation como requisito previo para la elegibilidad de examen de Lead Implementer y Lead Auditor. La cohorte en sí dura dos días y cubre el modelo mental del sistema de gestión, la estructura de ISO 27001:2022 y el conjunto de controles del Anexo A. Para profesionales sénior con experiencia previa en ISO 27001 u otra credencial de un sistema de gestión ISO, el requisito de Foundation a veces puede eximirse mediante el reconocimiento por parte de PECB de formación equivalente. Compruébelo antes de reservar; mapeamos su caso en la llamada de descubrimiento. ### ¿Cómo es el examen de Lead Implementer? Tres horas, a libro abierto, en línea a través de la plataforma PECB. Una mezcla de preguntas de opción múltiple y preguntas de escenario tipo ensayo. Las preguntas de escenario son donde la mayoría de los candidatos pierden puntos: recibe el contexto de una organización ficticia y luego debe aplicar la metodología del ISMS de principio a fin, definir el alcance, identificar riesgos, proponer controles, justificar la estructura de la SoA, planificar la revisión por la dirección. La preparación previa a la cohorte sobre la metodología es innegociable. ### ¿Cuánto cuesta en Europa en 2026? Precios estándar de PECB presencial con instructor en Europa a principios de 2026: Foundation alrededor de 1.200 euros, Lead Implementer de 2.800 a 3.200 euros, Lead Auditor de 2.800 a 3.200 euros. Incluye el curso, los materiales oficiales de PECB, la tasa de certificación, el examen, una repetición y la credencial de por vida. La modalidad a su propio ritmo suele ser entre un 30% y un 40% más barata, pero más lenta de completar. Las cohortes internas se cotizan por equipo en lugar de por plaza; espere de 12.000 a 18.000 euros para una cohorte de Lead Implementer de 5 días de hasta 12 alumnos, presencial o virtual. ### ¿Se solapan las credenciales de PECB e ISACA? Cubren terrenos relacionados pero distintos. PECB emite credenciales sobre normas ISO (ISO 27001, 27005, 31000, 22301, 42001…) y sobre regulaciones de la UE (NIS 2, DORA). ISACA emite credenciales sobre disciplinas profesionales (auditoría, gestión de seguridad, riesgo, gobierno, privacidad) sustentadas en COBIT y en los marcos de ISACA. La mayoría de los profesionales sénior tienen ambas: un ISO 27001 Lead Implementer o Lead Auditor (PECB) más CISA o CISM (ISACA). La vía de auditoría (CISA → CRISC → ISO 27001 LA) es la secuencia canónica. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) - [ISO, ISO/IEC 27001:2022](https://www.iso.org/standard/27001) --- # ISO 42001 y la gobernanza de la IA: el mapa de certificaciones y formaciones. **URL:** https://cyberacademy.net/es/resources/pillars/iso-42001-ai-governance **Author:** Christophe Mazzola **Published:** 2026-06-24 **Last reviewed:** 2026-06-24 ## Definition La gobernanza de la IA es la disciplina de operar sistemas de IA bajo control: riesgo, transparencia, sesgo, validación, seguridad y exposición regulatoria. El sistema de gestión de referencia es ISO/IEC 42001, publicado en diciembre de 2023, el equivalente para la IA del ISMS de ISO 27001. El panorama de credenciales se divide en dos: ISO 42001 (PECB) para la capa del sistema de gestión, y las certificaciones ISACA Advanced in AI (AAIA para auditoría, AAIR para riesgo, AAISM para seguridad) para la capa de disciplina profesional. Ambas se corresponden con el EU AI Act y el NIST AI RMF. ## TL;DR - ISO/IEC 42001 es la norma de sistema de gestión para la IA (un sistema de gestión de IA, o AIMS), publicada en diciembre de 2023. Es el equivalente AIMS del ISMS de ISO 27001. PECB emite la vía Foundation, Lead Implementer y Lead Auditor. - La vía Advanced in AI de ISACA es la capa de disciplina profesional: AAIA (auditoría), AAIR (riesgo), AAISM (seguridad). Cada una presupone una certificación ISACA existente (CISA, CRISC, CISM). - El EU AI Act te dice qué demostrar para un sistema de alto riesgo. ISO 42001 te dice cómo organizar la prueba. El NIST AI RMF es el método operativo de riesgo que la alimenta. - Elige según el rol: construir el sistema, ISO 42001 Lead Implementer. Auditar la IA, AAIA. Gestionar el riesgo de IA, AAIR o PECB AI Risk Manager. Asegurar modelos, AAISM. Liderar la entrega de IA, CAIP. - No existe una única "certificación de gobernanza de la IA". Un profesional sénior combina la credencial de sistema de gestión ISO 42001 con una credencial de disciplina. ## Full content Pregunta a cinco proveedores sobre certificación de gobernanza de la IA y obtendrás cinco respuestas distintas, porque el mercado no se ha asentado. No hay un único certificado de gobernanza de la IA del modo en que hay un único CISM o un único CISA. Hay dos capas diferenciadas, emitidas por dos organismos distintos, que responden a dos preguntas distintas: cómo gobiernas la IA como organización, y cómo la auditas, evalúas su riesgo o la aseguras como profesional. Esta página mapea las dos capas sobre la norma (ISO/IEC 42001), la regulación (el EU AI Act) y el marco estadounidense (NIST AI RMF), y luego te dice qué credencial encaja con qué rol y cómo formar a un equipo sin enviar a todo el mundo al mismo curso de cinco días. Está escrita para el CISO, el responsable GRC o el auditor que tiene que tomar la decisión. ## Las dos capas de credenciales de gobernanza de la IA Toda credencial de gobernanza de la IA del mercado se sitúa en una de dos capas. - La capa del sistema de gestión responde a "¿cómo gobierna la organización su IA?". La referencia es ISO/IEC 42001, la norma internacional de sistema de gestión de IA. PECB emite una vía Foundation, Lead Implementer y Lead Auditor frente a ella, exactamente como hace con ISO 27001. - La capa de disciplina profesional responde a "¿qué hace este profesional con la IA?". La referencia es la vía Advanced in AI de ISACA: AAIA para auditores, AAIR para gestores de riesgo, AAISM para gestores de seguridad. Cada una es avanzada y presupone que ya posees la certificación ISACA correspondiente. Las dos capas son complementarias. Una función madura de gobernanza de la IA posee ambas: una credencial de sistema de gestión ISO 42001 para construir y operar el sistema, y una credencial de disciplina ISACA por cada función que opera dentro de él. ## ISO/IEC 42001: el sistema de gestión de IA ISO/IEC 42001:2023, publicada en diciembre de 2023, es la primera norma internacional para un sistema de gestión de IA (AIMS). Es el equivalente para la IA del ISMS de ISO 27001: una política, roles definidos, un proceso de evaluación del riesgo de IA, controles sobre el ciclo de vida del sistema de IA, un Anexo A de controles específicos de la IA y un ciclo de revisión por la dirección que mantiene todo el conjunto honesto. La vía de certificación PECB frente a ella refleja la de ISO 27001: - ISO 42001 Foundation (2 días) aporta el vocabulario y el modelo de sistema de gestión. Es el requisito previo para las credenciales sénior. - ISO 42001 Lead Implementer (5 días) te enseña a construir el AIMS: alcance, evaluación del riesgo de IA, la Declaración de Aplicabilidad, los controles, el ciclo operativo. Es la credencial para quien sea dueño de la gobernanza de la IA. - ISO 42001 Lead Auditor (5 días) te enseña a auditar un AIMS: evidencia, muestreo, técnica de entrevista, hallazgos. Es la credencial para la auditoría interna y para los auditores de los organismos de certificación. > **¿Elegir un solo curso de ISO 42001?** Casi siempre es Lead Implementer. Construyes el sistema mucho más a menudo de lo que auditas el de otra persona. ## La vía ISACA Advanced in AI: AAIA, AAIR, AAISM Las credenciales Advanced in AI de ISACA son la capa de disciplina profesional. Son avanzadas por diseño: cada una presupone que ya posees la certificación ISACA fundacional de esa disciplina, y cada una está mapeada sobre ISO 42001 y las obligaciones de alto riesgo del EU AI Act en lugar de enseñarse en el vacío. **Las tres credenciales ISACA Advanced in AI** | Credencial | Disciplina | Presupone | Diseñada para | | --- | --- | --- | --- | | AAIA — Advanced in AI Audit | Auditar sistemas, modelos y gobernanza de IA | CISA | Auditores de TI sénior, responsables de cumplimiento | | AAIR — Advanced in AI Risk | Evaluación, cuantificación, tratamiento y monitorización del riesgo de IA | CRISC | Gestores de riesgo de TI, CRO | | AAISM — Advanced in AI Security Management | Modelado de amenazas de IA, ciclo de vida seguro del modelo, operaciones de seguridad de IA | CISM | CISO, arquitectos de seguridad | Los tres cursos en Cyber Academy son AAIA, AAIR y AAISM. Elige por lo que haces, no por cuál es más reciente. ## Dónde encajan PECB AI Risk Manager y CAIP Otras dos credenciales PECB se sitúan junto a la vía ISO 42001. AI Risk Manager es una credencial de riesgo focalizada para profesionales que gestionan programas de riesgo específicos de IA (riesgo de modelo, sesgo, deriva, riesgo de modelos de terceros) sin el alcance completo de sistema de gestión de Lead Implementer. Certified Artificial Intelligence Professional (CAIP) es la credencial de profesional más amplia para quienes construyen y despliegan IA de forma responsable a lo largo del ciclo de vida, útil para líderes técnicos que necesitan el vocabulario de gobernanza sin ser dueños del AIMS. Si ya operas un programa de riesgo ISO 27001 y quieres extenderlo a la IA, AI Risk Manager es el puente más corto. Si lideras la entrega de IA y necesitas la alfabetización en gobernanza que el AI Act ahora te exige, CAIP es el mejor encaje. ## Cómo se corresponden las credenciales con el AI Act y el NIST AI RMF Ninguna de estas credenciales existe de forma aislada. Se enseñan frente a la regulación y los marcos que una función de gobernanza de la IA tiene que satisfacer realmente. **Qué responde cada instrumento** | Instrumento | Qué es | ¿Certificable? | Papel en tu programa | | --- | --- | --- | --- | | EU AI Act | Regulation (EU) 2024/1689 | No: evaluación de la conformidad, no certificación | Qué demostrar para un sistema de alto riesgo | | ISO/IEC 42001 | Norma de sistema de gestión de IA | Sí: certificación AIMS + credenciales PECB | Cómo organizar la prueba | | NIST AI RMF | Marco voluntario estadounidense de riesgo (Govern, Map, Measure, Manage) | No | Método operativo de riesgo que alimenta el sistema | | ISO/IEC 23894 | Guía de gestión del riesgo de IA | No | Metodología de riesgo, alineada con ISO, dentro del AIMS | La vía canónica para una organización europea: construir el AIMS con ISO 42001 Lead Implementer, mapear las obligaciones de alto riesgo del AI Act sobre los controles del AIMS y usar el NIST AI RMF o ISO 23894 como metodología de riesgo. La credencial ISACA Advanced equipa entonces a la función (auditoría, riesgo o seguridad) que tiene que operar dentro de ese sistema. ## Cómo formar a un equipo en gobernanza de la IA El error es enviar a todo el mundo al mismo curso. La gobernanza de la IA es transversal, y las funciones necesitan profundidades distintas. 1. Empieza con una base común. ISO 42001 Foundation, o una sesión de alfabetización sobre el AI Act que satisfaga la obligación de alfabetización en IA del Artículo 4 del Act, da a todos el mismo vocabulario antes de que se especialicen. 1. Envía a los responsables de gobernanza y cumplimiento a ISO 42001 Lead Implementer. Ellos construyen y operan el AIMS. 1. Envía a la auditoría interna a AAIA, a la función de riesgo a AAIR y a la función de seguridad a AAISM. Cada una opera dentro del AIMS desde su propio ángulo. 1. Añade ISO 42001 Lead Auditor solo si operas un programa de auditoría interna frente al AIMS o formas parte de un organismo de certificación. > **¿Formar a todo un equipo?** Una cohorte interna se factura por cohorte en lugar de por plaza y adapta los ejercicios a tu parque de IA real. La llamada de descubrimiento delimita qué roles necesitan qué credencial antes de que nadie reserve: la mayoría de los equipos compran de más plazas de Lead Implementer y de menos credenciales de disciplina. ## La decisión, en una línea Construir el sistema: ISO 42001 Lead Implementer. Auditar la IA: AAIA. Gestionar el riesgo de IA: AAIR o PECB AI Risk Manager. Asegurar modelos: AAISM. Liderar la entrega de IA y necesitar alfabetización en gobernanza: CAIP. No hay un único certificado de gobernanza de la IA, y quien te venda uno te está vendiendo una porción. ## FAQ ### ¿Existe una certificación de gobernanza de la IA y cuál debería cursar? No existe una única certificación de gobernanza de la IA. El espacio se divide en dos capas. La capa del sistema de gestión es ISO/IEC 42001: PECB emite Foundation (2 días), Lead Implementer (5 días, construir el AIMS) y Lead Auditor (5 días, auditar uno). La capa de disciplina profesional es la vía Advanced in AI de ISACA: AAIA para auditar la IA, AAIR para el riesgo de IA, AAISM para la gestión de la seguridad de la IA. Para quien gobierna la IA a nivel organizativo, ISO 42001 Lead Implementer es la piedra angular. Para quien audita, evalúa el riesgo o asegura la IA dentro de un rol GRC existente, la credencial ISACA Advanced correspondiente es la señal más fuerte. La mayoría de los profesionales sénior poseen una de cada. ### ¿Qué es ISO/IEC 42001 y cómo se relaciona con el EU AI Act? ISO/IEC 42001:2023 es la norma internacional para sistemas de gestión de IA, publicada en diciembre de 2023. Define cómo una organización establece, opera y mejora la gobernanza de sus sistemas de IA: política, roles, evaluación del riesgo de IA, el ciclo de vida del sistema de IA, un Anexo A de controles específicos de la IA y el ciclo de revisión por la dirección. Es el equivalente AIMS del ISMS de ISO 27001. La norma no satisface el EU AI Act por sí sola: el Act tiene requisitos técnicos específicos de producto para los sistemas de alto riesgo. Pero ISO 42001 aporta la base de sistema de gestión que reconocen los auditores y los organismos notificados. La vía canónica es ISO 42001 para construir el AIMS y, después, mapear las obligaciones de alto riesgo del AI Act sobre los controles del AIMS. ### AAIA vs AAIR vs AAISM: ¿qué certificación ISACA de IA? Tres enfoques sobre la IA, todos presuponen una credencial ISACA existente. AAIA (Advanced in AI Audit) es para auditores: auditar sistemas, modelos y gobernanza de IA, mapeados sobre ISO 42001 y el AI Act. Habitualmente se posee junto con CISA. AAIR (Advanced in AI Risk) es para profesionales del riesgo: evaluación, cuantificación, tratamiento y monitorización del riesgo de IA. Habitualmente se posee junto con CRISC. AAISM (Advanced in AI Security Management) es para responsables de seguridad: modelado de amenazas de IA, el ciclo de vida seguro del modelo y las operaciones de seguridad de IA. Habitualmente se posee junto con CISM. ### ¿Cómo formo a todo un equipo en gobernanza de la IA? Secuénciala por función. Empieza con una base común (ISO 42001 Foundation o una sesión de alfabetización sobre el AI Act que satisfaga el Artículo 4). Envía a los responsables de gobernanza y cumplimiento a ISO 42001 Lead Implementer; a la auditoría interna a AAIA; a la función de riesgo a AAIR; a la función de seguridad a AAISM. Para un despliegue en varios equipos, una cohorte interna se factura por cohorte y adapta los ejercicios a tu parque de IA. La llamada de descubrimiento delimita qué roles necesitan primero qué credencial: la mayoría de los equipos compran de más plazas de Lead Implementer y de menos credenciales de disciplina. ### ¿Dónde encaja el NIST AI RMF junto a ISO 42001? El NIST AI Risk Management Framework (AI RMF 1.0, enero de 2023) es el marco voluntario estadounidense estructurado en torno a Govern, Map, Measure y Manage. No es certificable ni es una norma de sistema de gestión: es un manual de juego para la función de riesgo. ISO 42001 y el NIST AI RMF son complementarios. ISO 42001 aporta el sistema de gestión certificable; el NIST AI RMF aporta el método operativo de riesgo que lo alimenta. Las organizaciones expuestas tanto al contexto europeo como al estadounidense operan un AIMS ISO 42001 con el NIST AI RMF, y la guía relacionada ISO/IEC 23894, como la metodología de riesgo de su interior. ## Official sources - [ISO, ISO/IEC 42001:2023 (AI management systems)](https://www.iso.org/standard/81230.html) - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [ISACA, Advanced in AI (AAIA / AAIR / AAISM)](https://www.isaca.org/credentialing) --- # AI Act: cumplimiento sin la abstracción. **URL:** https://cyberacademy.net/es/resources/pillars/ai-act **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition El AI Act de la UE (Regulation (EU) 2024/1689) es la primera regulación integral de IA del mundo. Cuatro niveles de riesgo: inaceptable (prohibido), alto (obligaciones exigentes y evaluación de la conformidad), limitado (transparencia), mínimo. Reglas específicas para los modelos de IA de uso general. Se aplica por fases hasta agosto de 2027. ISO 42001 es la respuesta de sistema de gestión a los requisitos organizativos del AI Act. ## TL;DR - Basado en el riesgo: las prácticas inaceptables están prohibidas (desde febrero de 2025), los sistemas de alto riesgo están fuertemente regulados, el riesgo limitado exige transparencia, el riesgo mínimo no se ve afectado. - Los sistemas de alto riesgo (empleo, infraestructuras críticas, educación, biometría, aplicación de la ley, justicia…) requieren gestión de riesgos, gobernanza de datos, documentación técnica, transparencia, supervisión humana, exactitud y ciberseguridad. - Las reglas de los modelos GPAI se aplican a los proveedores de IA de uso general, con obligaciones más estrictas para los modelos con riesgo sistémico. - Se requiere una evaluación de la conformidad antes de introducir un sistema de alto riesgo en el mercado de la UE. Se aplica el marcado CE. - Combínelo con ISO/IEC 42001 para la capa de sistema de gestión. El AI Act le dice qué debe demostrar; ISO 42001 le dice cómo organizar la prueba. ## Full content ## Clasifique el sistema antes de hacer cualquier otra cosa Toda decisión del AI Act parte de una pregunta: en qué nivel recae este sistema. Si se equivoca en la clasificación, o bien sobredimensiona un chatbot, o bien infraprotege una herramienta de cribado de CV que un regulador tratará como de alto riesgo. Los cuatro niveles no son un espectro por el que se desliza; son compartimentos discretos con consecuencias jurídicas distintas, y un solo producto puede situarse en más de uno si agrupa varias funciones. La clasificación es función de la finalidad prevista, no de la sofisticación técnica. Una simple regresión logística que decide quién obtiene un préstamo es de alto riesgo. Un gran modelo multimodal que recomienda recetas no lo es. El Act analiza para qué se usa el sistema y a quién afecta, de modo que el trabajo de clasificación corresponde a producto y cumplimiento de forma conjunta, no solo al equipo de ciencia de datos. **Los cuatro niveles de riesgo del AI Act de la UE y a qué le obliga cada uno** | Nivel de riesgo | Ejemplos | Obligación principal | Barrera antes del mercado | | --- | --- | --- | --- | | Inaceptable | Puntuación social, extracción no selectiva de imágenes para reconocimiento facial, sistemas manipuladores o que explotan vulnerabilidades | Prohibido. La práctica no puede introducirse en el mercado ni utilizarse en absoluto. | Prohibido de plano (las prohibiciones se aplican desde febrero de 2025) | | Alto | Empleo y contratación, puntuación crediticia, infraestructuras críticas, educación, biometría, aplicación de la ley, justicia | Conjunto completo de obligaciones: gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos, supervisión humana, exactitud, robustez, ciberseguridad | Evaluación de la conformidad más marcado CE y registro en la base de datos de la UE | | Limitado | Chatbots, reconocimiento de emociones, deepfakes y otros contenidos generados | Solo transparencia: informar a las personas de que interactúan con IA o de que el contenido está generado por IA | Sin evaluación de la conformidad; obligaciones de divulgación | | Mínimo | Filtros de spam, motores de recomendación, la mayoría de las funciones de IA de consumo | Sin obligaciones obligatorias bajo el Act; se fomentan los códigos voluntarios | Ninguna | La mayoría de las disputas en la sala de auditoría no son mínimo frente a alto; son alto frente a limitado en la frontera. Si no puede defender la clasificación por escrito, trátela como el nivel superior hasta que pueda. El curso AI Risk Manager recorre la lógica de clasificación y la evidencia que necesita para respaldar una decisión. ## Qué significa realmente "alto riesgo" en las operaciones El TL;DR enumera las siete áreas de obligación. La realidad operativa es que cada una es un proceso recurrente, no un documento que se redacta una sola vez. El cumplimiento del alto riesgo es un sistema que se opera durante toda la vida del producto, y el Act espera que demuestre que el sistema está activo, no que existió el día del lanzamiento. 1. La gestión de riesgos es continua. Identifica el uso indebido y los daños previsibles, los mitiga, prueba el riesgo residual y repite a lo largo de cada cambio sustancial. Un registro de riesgos congelado desde el lanzamiento es un hallazgo, no un control. 1. La gobernanza de datos abarca los conjuntos de entrenamiento, validación y prueba: representatividad, examen de sesgos, lagunas y procedencia de los datos. Tiene que mostrar qué comprobó y qué encontró, no limitarse a afirmar que los datos eran "buenos". 1. La documentación técnica es la columna vertebral del expediente. Describe el sistema, su finalidad, sus decisiones de diseño, sus métricas de rendimiento y sus limitaciones con suficiente detalle para que un tercero pudiera evaluar la conformidad a partir de ella. 1. El registro de eventos significa registro automático a lo largo de la vida del sistema para que los eventos sean trazables. Si algo sale mal, debe poder reconstruir qué hizo el sistema. 1. La supervisión humana tiene que diseñarse desde el principio, no añadirse después: las personas que supervisan el sistema necesitan la capacidad de comprender, intervenir y anular, y la interfaz tiene que hacerlo posible. 1. La exactitud, la robustez y la ciberseguridad tienen que medirse y declararse, y luego sostenerse en condiciones reales, incluidas las adversarias. "Funciona en la demo" no es una afirmación de robustez. Estas obligaciones se mapean limpiamente sobre un sistema de gestión, por lo que los equipos combinan el Act con ISO/IEC 42001. El curso ISO 42001 Lead Implementer construye el modelo operativo que convierte estas siete áreas en procesos repetibles con responsables, evidencia y ciclos de revisión. ## El flujo de trabajo de la evaluación de la conformidad La evaluación de la conformidad es la barrera que un sistema de alto riesgo supera antes de introducirse en el mercado de la UE. Para la mayoría de las categorías de alto riesgo se trata de una evaluación por control interno ejecutada por el proveedor frente a los requisitos del Act; ciertas categorías, en particular algunas de biometría, pasan por un organismo notificado. En cualquier caso, la secuencia es la misma, y conviene tratarla como un plan de proyecto y no como una lista de comprobación. 1. Confirme la clasificación y los requisitos aplicables para su caso de uso y categoría específicos. 1. Ponga en marcha los procesos de gestión de riesgos y de gobernanza de datos y ejecútelos, generando evidencia real en lugar de marcadores de posición. 1. Reúna la documentación técnica de modo que esté completa y sea internamente coherente con los registros, los resultados de las pruebas y el registro de riesgos. 1. Ejecute la evaluación de la conformidad (interna, o a través de un organismo notificado cuando sea necesario) y resuelva las brechas que aflore. 1. Redacte la declaración de conformidad de la UE, coloque el marcado CE y registre el sistema en la base de datos de la UE antes de salir al mercado. 1. Pase a la vigilancia poscomercialización desde el primer día, porque la obligación no termina con el lanzamiento. > **La documentación tiene que ser veraz, no solo completa** Los auditores hacen comprobaciones cruzadas. Si la documentación técnica afirma una cifra de exactitud que los registros de prueba no respaldan, o describe un control de supervisión humana que la interfaz real no ofrece, todo el expediente pierde credibilidad. Construya la documentación a partir de la evidencia, nunca al revés, y reconcilie el expediente con el sistema antes de que lo vea cualquier persona externa. ## Vigilancia poscomercialización y el calendario por fases Introducir un sistema en el mercado es el punto intermedio de la obligación, no el final. Los proveedores deben ejecutar un plan de vigilancia poscomercialización que recopile activamente datos de rendimiento e incidentes durante la vida desplegada del sistema, y los incidentes graves tienen que notificarse a las autoridades dentro de plazos definidos. Las modificaciones sustanciales pueden volver a desencadenar la evaluación de la conformidad, de modo que su proceso de gestión del cambio y su proceso del AI Act tienen que estar conectados. El calendario es por fases, lo que hace tropezar a los equipos que leen "agosto de 2027" y suponen que tienen hasta entonces para todo. Las prohibiciones sobre prácticas inaceptables ya se aplican. Las obligaciones GPAI y varias disposiciones de gobernanza llegan antes en el calendario, y las obligaciones de alto riesgo se incorporan por fases a lo largo del periodo hasta agosto de 2027 según la categoría. La postura correcta es mapear cada uno de sus sistemas a su propia fecha aplicable en lugar de planificar para un único precipicio. Operar el bucle de vigilancia e incidentes es donde los roles de auditor de IA y de riesgos demuestran su valía. El curso de auditor de IA (AAIA) cubre cómo auditar un sistema de gestión de IA frente a esta evidencia, y el curso de auditor de IA avanzado (AAIR) profundiza en el trabajo de prueba y aseguramiento que sustenta un expediente poscomercialización defendible. ## IA de uso general: una obligación separada que puede heredar Las reglas de los modelos GPAI se sitúan junto a los niveles de riesgo, no dentro de ellos. Si construye o ajusta un modelo de uso general, asume obligaciones de proveedor: documentación técnica del modelo, información para los implementadores posteriores, una política de derechos de autor y un resumen público del contenido de entrenamiento. Los modelos que se considera que conllevan un riesgo sistémico asumen deberes más estrictos, incluidas la evaluación del modelo, las pruebas adversarias y la notificación de incidentes. La trampa para la mayoría de los equipos está en el otro lado de esa relación. Si integra un modelo fundacional de terceros en su propio sistema de alto riesgo, no escapa del Act apuntando al proveedor del modelo. Hereda el riesgo de la integración y sigue siendo responsable de que su sistema alcance la conformidad. Trate la documentación del proveedor del modelo como una entrada para su expediente, no como un sustituto de este, y establezca las cláusulas contractuales de traspaso antes de lanzar. ## Errores frecuentes y la decisión que tiene delante - Tratar la clasificación como algo puntual. Una función que empezó como motor de recomendación se vuelve de alto riesgo en el momento en que condiciona una decisión de contratación o de crédito. Reclasifique en cada cambio material de finalidad. - Redactar la documentación como un artefacto de lanzamiento. El expediente tiene que mantenerse sincronizado con el sistema en funcionamiento; un expediente obsoleto es peor que uno incompleto porque induce activamente a error. - Confundir el sistema de gestión con la regulación. ISO 42001 organiza su prueba, pero por sí solo no hace que un sistema cumpla el AI Act. Sigue teniendo que clasificar, evaluar y registrar frente al Act. - Suponer que las obligaciones de proveedor GPAI cubren su integración. No lo hacen. Su sistema de alto riesgo necesita su propia historia de conformidad. - Planificar para un único plazo. Las fechas por fases significan que algunas obligaciones ya están vigentes mientras otras están a años de distancia; planifique por sistema, por categoría. La decisión que tienen delante la mayoría de los equipos no es si cumplir, sino cómo construir la capacidad de cumplir de forma repetida. Si parte de cero, el curso ISO 42001 Foundation da al equipo un vocabulario compartido, y el curso de gestión de la seguridad de la IA (AAISM) conecta las obligaciones de ciberseguridad y robustez del Act con el programa de seguridad que ya opera. Elija el rol más cercano a su brecha y construya hacia fuera desde ahí. > **Empiece por un inventario, no por una política** Antes de redactar un solo procedimiento, enumere cada sistema de IA y cada función de IA material que distribuye o utiliza, y clasifique cada uno. La mayoría de las organizaciones descubren que tienen más sistemas dentro del alcance de los que esperaban y menos que sean genuinamente de alto riesgo de los que temían. El inventario convierte una regulación abstracta en una lista de trabajo finita y priorizada. ## FAQ ### ¿Es mi sistema de IA de alto riesgo? El Annex III enumera ocho categorías de sistemas de IA de alto riesgo: biometría, infraestructuras críticas, educación y formación profesional, empleo y gestión de trabajadores, acceso a servicios públicos y privados esenciales, aplicación de la ley, migración y control de fronteras, justicia y procesos democráticos. Además de los sistemas de IA que actúan como componente de seguridad o producto cubierto por la legislación armonizada de la UE (Annex I). Si su sistema encaja en una de esas categorías, es de alto riesgo. Existe una excepción estrecha bajo el Article 6(3) cuando el sistema realiza una tarea procedimental limitada, mejora el resultado de una actividad humana previamente completada, detecta patrones de toma de decisiones sin sustituir la evaluación humana, o constituye una tarea preparatoria. Documente la excepción; el supervisor la pedirá. ### ¿Cuándo se aplica el AI Act? Aplicación por fases. Las prohibiciones (Article 5) y las obligaciones de alfabetización en IA se aplican desde el 2 de febrero de 2025. Las obligaciones GPAI se aplican desde el 2 de agosto de 2025. El grueso de las obligaciones de alto riesgo se aplica desde el 2 de agosto de 2026. Las obligaciones específicas de alto riesgo relativas a sistemas ya presentes en el mercado y a sistemas que recaen bajo el Annex I se aplican desde el 2 de agosto de 2027. Implicación práctica: si introduce un sistema de alto riesgo en el mercado de la UE en 2026, se aplica el grueso de las obligaciones del Chapter III. Empiece ya el trabajo de evaluación de la conformidad. ### ¿Cómo es la evaluación de la conformidad? Para la mayoría de los sistemas de alto riesgo, evaluación de la conformidad mediante control interno bajo el Annex VI. El proveedor declara la conformidad por sí mismo, sobre la base de: un sistema de gestión de la calidad, documentación técnica conforme al Annex IV, vigilancia poscomercialización, registro en la base de datos de la UE. Para ciertos sistemas de alto riesgo (en particular los sistemas de identificación biométrica), debe intervenir un organismo notificado de terceros (Annex VII). A continuación vienen el marcado CE y una declaración de conformidad de la UE. ### ¿Cuál es el papel de ISO/IEC 42001? ISO/IEC 42001 es la norma internacional para los sistemas de gestión de IA (AIMS), publicada a finales de 2023. Es el equivalente en AIMS del ISMS de ISO 27001. La norma no satisface el AI Act por sí sola, el Act tiene requisitos técnicos específicos de producto, pero proporciona la base de sistema de gestión que reconocerán los auditores y los organismos notificados. Una ruta típica de preparación: ISO 42001 Lead Implementer para construir el AIMS, luego mapear las obligaciones de alto riesgo del AI Act sobre los controles del AIMS, y luego ejecutar la evaluación de la conformidad para cada sistema dentro del alcance. ### ¿Qué pasa con los modelos de IA de uso general? Los Articles 51-56 regulan a los proveedores de modelos de IA de uso general. Obligaciones de base: documentación técnica, información para los proveedores posteriores, política de cumplimiento de los derechos de autor, resumen de los datos de entrenamiento. Los modelos GPAI con riesgo sistémico (actualmente aquellos con una potencia de cálculo de entrenamiento acumulada superior a 10^25 FLOP) afrontan obligaciones más estrictas, incluidas la evaluación del modelo, la evaluación y mitigación del riesgo sistémico y la notificación de incidentes. La AI Office de la Comisión Europea publica un código de buenas prácticas que aclara las obligaciones GPAI. La mayoría de los proveedores que no están en la frontera tecnológica se adhieren al código en lugar de negociar el cumplimiento desde primeros principios. ## Official sources - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [European Commission, AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) - [ISO, ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) --- # Resiliencia operativa: DORA, NIS 2 e ISO 22301 en un solo lugar. **URL:** https://cyberacademy.net/es/resources/pillars/operational-resilience-dora-nis-2-iso-22301 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition La resiliencia operativa es la capacidad de una organización para prestar servicios críticos a través de una disrupción y, después, recuperarse. Tres marcos la regulan en Europa: ISO 22301 (norma de BCMS, la capa operativa), NIS 2 (obligación de continuidad de negocio del Article 21 para las entidades en su ámbito), DORA (Articles 11-12 para las entidades financieras, más pruebas específicas). Un único programa puede satisfacer los tres; gestionarlos como flujos de trabajo separados duplica el esfuerzo y genera inconsistencias. ## TL;DR - ISO 22301 es la columna vertebral operativa: BIA, objetivos de recuperación, BCP, runbooks, ejercicios de simulación (tabletop) y BCMS bajo revisión por la dirección. - NIS 2 añade la notificación de incidentes (alerta temprana a las 24 horas, notificación a las 72 horas, informe a un mes) y la continuidad de la cadena de suministro. - DORA añade las pruebas específicas para entidades financieras (pruebas de penetración basadas en amenazas para las entidades significativas cada tres años), el registro de terceros de ICT y la supervisión a nivel de ESA para los proveedores críticos. - Lead Operational Resilience Manager (credencial PECB) está diseñado específicamente para integrar los tres. - Mapea una vez, audita tres: un único BCMS alineado con 22301 y con asignaciones de controles de NIS 2 y DORA satisface las tres auditorías. ## Full content ## Por qué un programa, y no tres El instinto dentro de la mayoría de las organizaciones es tratar ISO 22301, NIS 2 y DORA como tres proyectos de cumplimiento separados, a menudo a cargo de tres equipos distintos: continuidad de negocio, operaciones de seguridad y una función de regulación financiera o de riesgos. Esa es la forma más cara de hacerlo. Terminas con tres análisis de impacto en el negocio que no coinciden sobre qué servicios son críticos, tres conjuntos de objetivos de recuperación que nadie concilia y tres calendarios de ejercicios que agotan a las mismas personas. Los auditores detectan las costuras de inmediato. Los marcos no son competidores. ISO 22301 te da el sistema de gestión: el análisis de impacto en el negocio (BIA), los objetivos de tiempo de recuperación y de punto de recuperación, los planes de continuidad y de recuperación, los ejercicios y el bucle de revisión por la dirección. NIS 2 y DORA no sustituyen nada de eso. Añaden obligaciones por encima, sobre todo en torno a la notificación de incidentes, el aseguramiento de la cadena de suministro y (para DORA) un régimen de pruebas específico. Si tu BCMS está bien construido, las capas regulatorias se acoplan a él en lugar de duplicarlo. Construye primero la columna vertebral. El curso ISO 22301 Lead Implementer es el que te enseña a levantar el sistema de gestión del que cuelga todo lo demás; si solo necesitas entender la estructura y el vocabulario, comienza con el curso ISO 22301 Foundation. ## Qué añade realmente cada marco La forma honesta de leer los tres es como un núcleo operativo más dos capas regulatorias. ISO 22301 es el núcleo porque es el único de los tres que prescribe cómo construir y mantener la propia capacidad de continuidad. NIS 2 y DORA dan por supuesto que esa capacidad existe y luego imponen deberes encima: a quién debes informar cuando algo se rompe, con qué rapidez y cómo debes demostrar que la capacidad funciona. **Cómo encajan ISO 22301, NIS 2 y DORA** | Marco | Qué añade por encima del núcleo | A quién se aplica | | --- | --- | --- | | ISO 22301 | El propio sistema de gestión de la continuidad de negocio: BIA, RTO/RPO, planes de continuidad y de recuperación, runbooks, ejercicios, revisión por la dirección. La columna vertebral operativa que los otros dos dan por supuesta. | Cualquier organización, de forma voluntaria. Certificable pero no exigida legalmente. | | NIS 2 | Plazos de notificación de incidentes (alerta temprana, notificación, informe final), deberes de continuidad de negocio y de gestión de crisis, seguridad de la cadena de suministro y responsabilidad de la dirección. | Entidades esenciales e importantes en sectores designados de toda la UE (energía, transporte, salud, infraestructura digital, administración pública y más). | | DORA | Resiliencia de ICT del sector financiero: un programa de pruebas de resiliencia operativa digital que incluye pruebas de penetración basadas en amenazas para las entidades significativas, el registro de terceros de ICT y la supervisión directa de los proveedores críticos de ICT. | Entidades financieras de la UE (bancos, aseguradoras, empresas de inversión, proveedores de criptoactivos) y sus terceros críticos de ICT. | Lee la tabla de arriba abajo y el diseño se vuelve evidente. Implementas ISO 22301 una vez. NIS 2 y DORA te dicen entonces qué evidencia quiere ver el regulador de ese único sistema, y DORA añade una disciplina de pruebas que va más allá de los ejercicios de simulación (tabletop) que ISO 22301 espera. ## Cómo funciona en la operación En términos del día a día, la integración vive en tres artefactos, y acertar con ellos es la mayor parte del trabajo. El primero es un catálogo de servicios y un BIA únicos y autorizados. Decide una sola vez qué servicios son críticos, cuál es su tolerancia a la disrupción y de qué dependen. Cada marco lee entonces de esa única fuente. Si tu alcance de NIS 2 y tu lista de funciones críticas o importantes de DORA no coinciden con tu BIA de ISO 22301, ya has perdido el argumento de la auditoría antes de que empiece. El segundo es una cadena de incidentes unificada. ISO 22301 quiere que detectes, respondas e invoques los planes de continuidad. NIS 2 y DORA quieren que notifiques, contra reloj, a una autoridad competente. Construye un único proceso de detección y triaje cuya salida alimente tanto la respuesta de continuidad interna como el flujo de notificación regulatoria. El reloj de notificación arranca en el momento del conocimiento, así que el cuello de botella rara vez es el plan de continuidad; es la decisión de si un evento es notificable y la velocidad para redactar la notificación temprana. Las plantillas de notificación previamente redactadas y un responsable de escalado claro valen más que cualquier herramienta aquí. El tercer artefacto es el programa de pruebas y ejercicios, y aquí es donde DORA aprieta más fuerte. Los ejercicios de ISO 22301 validan los planes; DORA exige un programa de pruebas documentado y, para las entidades significativas, pruebas de penetración basadas en amenazas en un ciclo plurianual. El curso DORA Lead Manager cubre el régimen de pruebas y el registro de terceros de ICT con la profundidad que exige la regulación, mientras que el curso Lead Operational Resilience Manager es el que está diseñado específicamente para gestionar los tres marcos como un único programa. > **Mapea una vez, evidencia tres** Mantén una única hoja de cálculo de asignación de controles que liste cada control una sola vez y lo etiquete con las cláusulas que satisface (ISO 22301, NIS 2 Article 21, DORA Articles 11-12). Cuando un auditor de cualquiera de los marcos pida evidencia, filtras por su etiqueta y entregas los mismos artefactos subyacentes. Este único hábito es la diferencia entre una auditoría tranquila y tres frenéticas. ## La decisión: certificar, alinear o ambas Una pregunta habitual es si necesitas la certificación ISO 22301 para satisfacer NIS 2 o DORA. No la necesitas. Ninguna regulación exige el certificado. Pero la norma es el modelo más ampliamente reconocido para la capacidad que ambas regulaciones dan por supuesta, así que la mayoría de los equipos se alinean con ISO 22301 incluso cuando eligen no certificarse. La decisión se divide con claridad: alinéate con ISO 22301 para obtener un BCMS coherente y defendible; certifícate por encima solo si un cliente, una licitación o un consejo quiere un aseguramiento de terceros sobre ello. Si decides buscar el certificado, comprende la perspectiva de la auditoría desde ambos lados de la mesa. Los implementadores construyen el sistema; los auditores comprueban si se sostiene. Para realizar la auditoría de certificación (interna o como organismo de certificación), el curso ISO 22301 Lead Auditor enseña la metodología de auditoría y cómo evaluar un BCMS frente a la norma, que también es la forma más rápida de aprender con qué evidencia se juzgará tu propio programa. ## Dónde fallan los programas Los fallos recurrentes son predecibles, y casi todos provienen de tratar los marcos como separados en lugar de en capas. 1. Tres BIA que no coinciden. Continuidad, seguridad y finanzas definen la criticidad de forma distinta cada uno. Corrígelo exigiendo un único BIA que las tres funciones firmen. 1. Planes que pasan el ejercicio pero fallan en el evento. Los ejercicios de simulación (tabletop) que recorren una presentación de diapositivas no demuestran nada. Prueba la invocación, no la narración: haz realmente la conmutación por error, restaura realmente desde la copia de seguridad, contacta realmente con las personas del árbol de llamadas. 1. Confundir las funciones de continuidad, recuperación y respuesta a incidentes. La continuidad de negocio mantiene el servicio en marcha, la recuperación ante desastres restaura la tecnología y la respuesta a incidentes contiene la causa. Son disciplinas distintas que deben traspasarse el control de forma limpia. 1. Pasar por alto el reloj de notificación. El plan de continuidad funcionó pero nadie presentó a tiempo la alerta temprana. La notificación regulatoria es una obligación separada, con un plazo acotado, y necesita su propio responsable. 1. Tratar la gestión de crisis como una ocurrencia tardía. Cuando un incidente escala, la toma de decisiones, no la recuperación técnica, es el punto de fallo. Dos de esos fallos tienen remedios dedicados. El curso Lead Disaster Recovery Manager separa la recuperación tecnológica de la continuidad de negocio para que las dos dejen de confundirse, y el curso Certified Lead Crisis Manager construye la estructura de mando, comunicación y decisión que aguanta cuando un incidente se convierte en una crisis. ## La realidad de la sala de auditoría Lo que un evaluador de cualquiera de los tres marcos sondea en realidad es si tu resiliencia es real o de papel. Pedirán el BIA y luego preguntarán quién lo aprobó y cuándo se revisó por última vez. Pedirán tu último ejercicio y luego preguntarán qué falló y qué cambiaste como resultado, porque un ejercicio sin hallazgos es una señal de alarma, no un certificado de buena salud. Para las entidades DORA, pedirán el programa de pruebas y el registro de terceros y esperarán que ambos estén al día, no reconstruidos la semana anterior. Los equipos que aprueban con calma son los que gestionan un único programa: un BIA, una cadena de incidentes que alimenta tanto la respuesta interna como la notificación regulatoria, un calendario de ejercicios que de verdad rompe cosas y un único mapeo de controles que les permite responder a tres reguladores desde la misma base de evidencia. Construye bien la columna vertebral de ISO 22301, acopla deliberadamente sobre ella las obligaciones de NIS 2 y DORA, y la frase que debería describir tus auditorías es: mapea una vez, audita tres. ## FAQ ### ¿Necesito la certificación ISO 22301 bajo NIS 2 o DORA? No. Ni NIS 2 ni DORA exigen la certificación ISO 22301. Ambos requieren que la organización opere capacidades de continuidad de negocio y de resiliencia que logren resultados específicos (recuperarse en los plazos acordados, notificar incidentes dentro de los plazos, probar los planes). Un BCMS conforme con ISO 22301 demuestra esas capacidades de forma clara ante un supervisor. En la práctica, las entidades financieras y los operadores de importancia vital a menudo buscan la certificación ISO 22301 porque la evidencia de auditoría que exigen NIS 2 y DORA coincide casi uno a uno con la evidencia de la certificación. ### ¿Cuál es la relación entre BCP, DR y respuesta a incidentes? Tres disciplinas que se solapan. Los Planes de Continuidad de Negocio (BCP) cubren cómo el negocio sigue operando a través de una disrupción: dotación de personal, sitios alternativos, soluciones provisionales, comunicación. La Recuperación ante Desastres (DR) cubre la restauración específica de TI de los sistemas y los datos. La Respuesta a Incidentes (IR) cubre el ciclo de detección a recuperación de los incidentes de seguridad. Un programa maduro los gestiona como uno solo. El mismo manual de actuación recorre desde la detección del incidente (IR) hasta la recuperación de los sistemas (DR) y la continuación de la operación del negocio (BCP). Distintos equipos pueden ejecutar distintas fases, pero el plan está integrado. ### ¿Qué son las pruebas de penetración basadas en amenazas bajo DORA? TLPT es el ejercicio de red team supervisado por el regulador que se exige a las entidades financieras significativas bajo DORA, al menos cada tres años. Construido sobre TIBER-EU. Impulsado por inteligencia (un equipo de inteligencia de amenazas independiente elabora el perfil del atacante), dirigido a funciones críticas o importantes, supervisado por la autoridad nacional. TLPT es un trabajo de varios meses y de varios cientos de miles de euros. Es la prueba de resiliencia más rigurosa a la que se enfrentará un CISO financiero, y la que expone al SOC, las reglas de detección y la cadena de respuesta a incidentes tal y como son en realidad. ### ¿Cómo estructuro un único programa de resiliencia? Comienza con el BCMS (columna vertebral de ISO 22301): alcance, BIA, objetivos de recuperación, planes, pruebas, revisión por la dirección. Añade los procedimientos de notificación de incidentes de NIS 2 y las obligaciones de continuidad de la cadena de suministro del Article 21. Añade el calendario de pruebas específico de DORA, el registro de terceros de ICT y la clasificación de incidentes para las entidades financieras. Mapea los controles en un único documento de asignación que muestre qué cláusula de qué marco satisface cada control. Los auditores reconocen el mapeo y dejan de hacer preguntas duplicadas. ## Official sources - [ISO, ISO 22301:2019 Business continuity management](https://www.iso.org/standard/75106.html) - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) --- # GDPR en 2026: lo que cambió desde 2018. **URL:** https://cyberacademy.net/es/resources/pillars/gdpr-2026 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition En 2026, el GDPR sigue siendo el reglamento de la UE que rige los datos personales (Regulation (EU) 2016/679, en vigor desde mayo de 2018). Lo que cambió desde 2018: el marco de transferencias internacionales (Schrems II, nuevas SCC, EU-US Data Privacy Framework), la intensidad sancionadora (CNIL, DPC, AEPD como las autoridades activas), la interacción con la AI Act sobre el tratamiento automatizado y las aclaraciones del CJEU sobre el consentimiento, el interés legítimo y el derecho al olvido. ## TL;DR - El GDPR en sí no ha sido modificado. Lo que se movió es la jurisprudencia, las directrices del EDPB, las SCC y el marco de transferencias internacionales. - Schrems II invalidó el Privacy Shield en 2020. El EU-US Data Privacy Framework (DPF) lo reemplazó en julio de 2023; las transferencias a importadores estadounidenses certificados bajo el DPF ya no requieren medidas complementarias. - Las SCC de 2021 reemplazaron a las versiones de 2010. Toda transferencia fuera del EEE sin una decisión de adecuación necesita un Transfer Impact Assessment documentado. - La actividad sancionadora del EDPB y de las autoridades nacionales alcanza una intensidad récord. Casos relevantes de 2023-2025: Meta (1.200 millones de euros, transferencias), LinkedIn (310 millones de euros, publicidad comportamental), Clearview AI (varias autoridades). - Interacción con la AI Act: los sistemas de IA de alto riesgo que tratan datos personales deben cumplir ambas. DPIA + evaluación de conformidad de la AI Act de forma conjunta. ## Full content ## Por qué el texto se quedó quieto y la práctica se movió El GDPR no ha sido reescrito. Los números de artículo que aprendió en 2018 son los números de artículo que aplica en 2026. Lo que cambió está una capa por debajo: la jurisprudencia que interpreta el texto, las directrices del EDPB que lo operativizan, las cláusulas contractuales tipo que dan soporte a sus transferencias y el mecanismo de adecuación que gobierna dónde pueden aterrizar legalmente los datos. Un programa de privacidad construido en 2018 y nunca tocado desde entonces no está mal sobre el papel. Está desfasado en la práctica, y lo desfasado es lo que la actividad sancionadora encuentra ahora. Esta página es para la persona que ya entiende el reglamento y necesita saber qué actualizar. Da por supuesto que sabe definir qué son datos personales, un responsable y una base jurídica. Se centra en las cuatro piezas en movimiento que realmente generan hallazgos en 2026: las transferencias internacionales, el Transfer Impact Assessment, el solapamiento con la AI Act y la cuestión de si está obligado a nombrar un Data Protection Officer. ## Transferencias internacionales: el árbol de decisión, no el titular La mayoría de los equipos conoce los titulares. Schrems II invalidó el Privacy Shield en 2020. El EU-US Data Privacy Framework lo reemplazó en 2023. Las SCC de 2021 reemplazaron a las versiones de 2010. Los titulares son ciertos y casi inútiles por sí solos, porque el verdadero trabajo consiste en hacer coincidir una transferencia concreta con un instrumento concreto y después decidir si hace falta un Transfer Impact Assessment además. Eso es un árbol de decisión, y lo recorre por cada flujo de datos, no una sola vez para toda la empresa. Empiece por el destino. Si el importador se encuentra en un país con una decisión de adecuación de la UE vigente, transfiere sobre la base de la decisión de adecuación y no necesita SCC ni un TIA para ese flujo. Si el destino es Estados Unidos y el importador está autocertificado bajo el Data Privacy Framework para las categorías de datos pertinentes, ese flujo se apoya en el DPF como su propia base de adecuación: sin SCC, sin medidas complementarias. En cuanto sale de ambos supuestos, queda bajo las garantías del Article 46, lo que en la práctica significa las SCC de 2021, y las SCC conllevan una obligación de TIA que Schrems II hizo no opcional. **Escenario de transferencia, instrumento requerido y si procede un TIA** | Escenario de transferencia | Instrumento necesario | ¿TIA requerido? | | --- | --- | --- | | Del EEE a un país con una decisión de adecuación vigente | Decisión de adecuación (sin contrato adicional) | No | | Del EEE a un importador estadounidense autocertificado bajo el DPF, para datos cubiertos | Certificación DPF (actúa como adecuación) | No | | Del EEE a un importador estadounidense NO incluido en el DPF | SCC de 2021 | Sí | | Del EEE a un tercer país no adecuado (caso general) | SCC de 2021 | Sí | | Transferencias intragrupo entre múltiples entidades y países | Binding Corporate Rules (o SCC) | Sí (evaluado por destino) | | Transferencia ulterior de su encargado a su propio subencargado en el extranjero | SCC en cascada dentro de la cadena de encargados | Sí (la cadena hereda la obligación) | > **El DPF no es un pase general para EE. UU.** Que un proveedor estadounidense esté "incluido en la lista DPF" no significa que todos los flujos hacia él estén cubiertos. La certificación se limita a categorías de datos específicas y a organizaciones que figuran en la lista activa. Confirme que el importador está actualmente certificado para los datos que envía, y tenga preparado un plan de contingencia con SCC, porque una decisión de adecuación puede ser impugnada y suspendida, como ocurrió con el Privacy Shield. Una impugnación al DPF al estilo Schrems es precisamente el riesgo que un programa resiliente anticipa. ## El Transfer Impact Assessment en la operación Un TIA es el documento que responde a una pregunta: ¿la legislación y la práctica del país de destino socavan la protección que sus SCC prometen sobre el papel? No es una casilla que marcar. Es una pequeña pieza de análisis jurídico y técnico que produce por cada transferencia (o por cada grupo de transferencias materialmente idénticas) y conserva en archivo para el día en que un regulador pregunte. En la práctica, un TIA defendible hace cuatro cosas. Describe la transferencia de forma concreta: quién exporta, quién importa, qué datos, qué volumen, qué finalidad. Evalúa el régimen jurídico de destino, con especial atención a las facultades de acceso gubernamental y a si un interesado dispone de algún recurso efectivo. Identifica medidas complementarias cuando el régimen jurídico es débil, y la medida que realmente marca la diferencia es el cifrado que usted controla, en el que el importador nunca posee las claves. Y registra una conclusión razonada: proceder, proceder con medidas o no transferir. 1. Mapee el flujo con precisión, incluidas las transferencias ulteriores que su encargado realice a subencargados. Los flujos que olvida son los que afloran en una brecha. 1. Evalúe la legislación de destino frente a los criterios del EDPB, no según su intuición sobre el país. 1. Aplique medidas complementarias cuando sea necesario, y trate el cifrado robusto con gestión propia de las claves como la medida técnica por defecto, en lugar de promesas contractuales por sí solas. 1. Documente la conclusión y féchela, después fije un detonante de revisión para que no expire en silencio. > **Vincule el TIA a su RoPA, no a una carpeta** Los equipos que superan las auditorías de transferencias con soltura son aquellos cuyo Record of Processing Activities señala cada flujo que sale del EEE, y cada flujo señalado apunta a un TIA vigente. Cuando el registro y las evaluaciones están vinculados, "muéstreme sus transferencias" lleva minutos. Cuando viven en unidades separadas, lleva una semana de pánico y suele sacar a la luz un flujo no documentado. ## Donde el GDPR se encuentra con la AI Act La AI Act no reemplaza al GDPR ni lo relaja. Cuando un sistema de IA trata datos personales, ambos se aplican en su totalidad y usted satisface ambos. La forma más clara de ver el solapamiento es a través del artefacto que cada régimen espera. El GDPR exige un Data Protection Impact Assessment cuando es probable que el tratamiento suponga un alto riesgo para las personas. La AI Act exige una evaluación de conformidad, documentación técnica y (para algunos sistemas) una evaluación de impacto sobre los derechos fundamentales para la IA de alto riesgo. Son documentos diferentes que responden a preguntas diferentes, y un sistema de IA de alto riesgo que trata datos personales necesita ambos, coherentes entre sí. Los puntos de fricción son problemas conocidos del GDPR con ropa nueva. Las decisiones automatizadas con efecto jurídico o similarmente significativo ya activaban las obligaciones del Article 22; la AI Act añade encima deberes de transparencia y supervisión humana. Los datos de entrenamiento plantean cuestiones de base jurídica y de limitación de la finalidad que no desaparecen porque la salida sea un modelo. La elaboración de perfiles y las inferencias siempre estuvieron en el ámbito de aplicación. La regla práctica para 2026: no ejecute una línea de trabajo de gobernanza de la IA que ignore a su DPO, y no ejecute un programa de privacidad que finja que el entrenamiento de modelos es problema de otro. Las dos evaluaciones deben remitirse la una a la otra. Los ingenieros de privacidad que tienen que tender puentes entre estos regímenes en las decisiones de construcción son precisamente el público de la certificación CDPSE, que se estructura en torno a la gobernanza, la arquitectura y el ciclo de vida del dato más que al texto legal por sí solo. Para operativizar la privacidad como un sistema de gestión que conviva limpiamente junto a un ISMS, el curso ISO 27701 Foundation cubre el modelo PIMS, y el curso ISO 27701 Lead Implementer le guía por su construcción y operación. ## La actividad sancionadora es una señal, no solo un riesgo Lea la actividad sancionadora reciente como un mapa de dónde están mirando las autoridades, porque le indica dónde se encuentra probablemente su propia exposición. El patrón a lo largo de 2023 a 2025 es coherente. Las transferencias internacionales produjeron las mayores sanciones individuales, con la decisión sobre Meta (1.200 millones de euros) girando en torno a los flujos de datos entre la UE y EE. UU. La publicidad comportamental y la base jurídica para la segmentación publicitaria motivaron la decisión sobre LinkedIn (310 millones de euros). Los datos biométricos extraídos mediante scraping impulsaron acciones reiteradas contra Clearview AI ante múltiples autoridades. Las autoridades activas son las que cabría esperar: la CNIL en Francia, la DPC en Irlanda para las grandes plataformas y la AEPD en España. La conclusión operativa es dejar de tratar la actividad sancionadora como el titular de otro. Si las transferencias, el consentimiento publicitario y el tratamiento biométrico o cercano a la IA son donde caen las multas, esos son los tres expedientes sobre los que un regulador tiene estadísticamente más probabilidad de preguntarle. Un programa que puede presentar un TIA vigente, un registro de consentimiento defendible y una DPIA para su tratamiento de mayor riesgo es un programa que sobrevive a las preguntas que realmente se formulan. ## ¿Necesita realmente un DPO? La cuestión del DPO es la que más a menudo se responde por reflejo en lugar de por el texto. El Article 37 hace obligatorio un DPO en tres situaciones: usted es una autoridad u organismo público; sus actividades principales consisten en una observación habitual y sistemática de los interesados a gran escala; o sus actividades principales consisten en el tratamiento a gran escala de categorías especiales de datos o de datos sobre condenas penales. Si no se da ninguna de esas, el GDPR no obliga al nombramiento, aunque algunas legislaciones nacionales añaden sus propios detonantes y un DPO voluntario suele ser la opción sensata. La expresión que decide la mayoría de los casos reales es "actividades principales". Un hospital observa datos de salud como su actividad principal, así que necesita un DPO. Un fabricante que gestiona nóminas trata datos personales, pero eso es una función de apoyo, no una actividad principal, así que las nóminas por sí solas no activan la obligación. Los errores se concentran en los límites: nombrar a alguien que carece de la independencia y la línea de reporte que exige el Article 38, designar un DPO que tiene un conflicto de interés porque también es propietario del tratamiento que se supone debe supervisar, o nombrar sobre el papel sin dar autoridad al rol. Un DPO que no puede llegar al consejo y no puede decir que no es un hallazgo esperando a ser redactado. Si el rol es suyo para cubrir o para supervisar, la profundidad importa. El curso GDPR Foundation es el punto de partida adecuado para el equipo en torno al rol, y el curso GDPR Certified Data Protection Officer está pensado para la persona que ostenta el cargo, cubriendo la independencia, las tareas y la rendición de cuentas que el reglamento realmente exige. ## Qué actualizar antes de su próxima auditoría Ponga al día las piezas en movimiento y el resto del programa prácticamente se cuida solo. Confirme que toda transferencia está sobre las SCC de 2021, no sobre el conjunto retirado de 2010, porque las cláusulas heredadas son un hallazgo inmediato. Compruebe que cada transferencia no adecuada tiene un TIA fechado y vinculado desde su RoPA. Verifique que cualquier proveedor estadounidense del que dependa está actualmente certificado bajo el DPF para los datos que envía, y que dispone de un plan de contingencia con SCC si no lo está. Asegúrese de que su tratamiento de mayor riesgo cuenta con una DPIA, y de que todo lo impulsado por IA tiene a su lado los artefactos de la AI Act. Por último, vuelva a contrastar la cuestión del DPO frente a sus actividades principales reales, en lugar de la respuesta que dio en 2018. > **La realidad de la sala de auditoría** Los reguladores rara vez reprochan a las organizaciones la existencia de una transferencia o de un sistema de IA. Les reprochan la ausencia del documento que demuestra que la decisión se tomó de forma deliberada. La respuesta defendible a casi cualquier pregunta difícil es "aquí está la evaluación, aquí está la fecha, aquí está quién la firmó". Un programa que puede presentar esas tres cosas a demanda está haciendo su trabajo; uno que no puede está expuesto, por muy cuidadoso que sea su manejo cotidiano. ## FAQ ### ¿Sigo necesitando SCC ahora que se adoptó el EU-US DPF? Para transferencias a importadores estadounidenses autocertificados bajo el EU-US Data Privacy Framework, no: la decisión de adecuación de julio de 2023 cubre esas transferencias. Compruebe la certificación del importador en la lista DPF del Department of Commerce. Para transferencias a importadores estadounidenses no incluidos en el DPF, o transferencias a cualquier otro tercer país sin decisión de adecuación, se requieren las SCC de 2021 (u otra herramienta de transferencia) más un Transfer Impact Assessment. ### ¿Qué es un Transfer Impact Assessment y cuándo lo necesito? Un TIA es el análisis documentado exigido desde Schrems II para cualquier transferencia de datos personales fuera del EEE sin una decisión de adecuación. Evalúa si las leyes del país de destino ofrecen un nivel de protección esencialmente equivalente al garantizado dentro de la UE, e identifica medidas complementarias en caso contrario. Necesita un TIA para cada transferencia de este tipo, por cada flujo de transferencia. Las EDPB Recommendations 01/2020 proporcionan la metodología. La mayoría de las organizaciones que usan proveedores SaaS no europeos subestiman el trabajo del TIA y se apoyan en la plantilla del proveedor, que por sí sola no es jurídicamente suficiente. ### ¿Cómo interactúa la AI Act con el GDPR? La AI Act es una capa adicional sobre el GDPR, no un reemplazo. Cuando los sistemas de IA de alto riesgo tratan datos personales, ambos reglamentos se aplican: el GDPR para la base jurídica, los derechos de los interesados, la DPIA y el marco de transferencias internacionales; la AI Act para la evaluación de conformidad, la gestión de riesgos, la documentación técnica y la supervisión humana. En la práctica, las organizaciones integran la DPIA y la evaluación de conformidad de la AI Act en un único documento siempre que es posible, para evitar trabajo duplicado y tratamientos del riesgo incoherentes. ### ¿Qué tendencias sancionadoras debo vigilar? Tres tendencias desde 2022: (1) una mayor cooperación entre las autoridades de control (decisiones de ventanilla única, investigaciones conjuntas), con la DPC en Irlanda aún liderando los casos transfronterizos contra las tecnológicas estadounidenses, pero con las decisiones vinculantes del EDPB endureciendo su margen; (2) multas relevantes sobre publicidad comportamental y patrones engañosos (Meta, LinkedIn, Amazon, Google); (3) actividad sancionadora sobre cookies y tecnologías de seguimiento bajo la ePrivacy Directive (la CNIL especialmente activa). Cabe esperar que la tendencia continúe: más decisiones vinculantes transfronterizas, mayor escrutinio del interés legítimo como base para el tratamiento comportamental y una atención creciente al tratamiento relacionado con la IA bajo el GDPR Article 22 (decisiones automatizadas). ### ¿Necesita mi organización un DPO? Los GDPR Articles 37 a 39 exigen un DPO cuando: (a) el responsable o encargado es una autoridad u organismo público; (b) las actividades principales requieren una observación habitual y sistemática de los interesados a gran escala; (c) las actividades principales consisten en el tratamiento a gran escala de categorías especiales de datos o de datos personales relativos a condenas penales. Más allá de la exigencia legal, muchas organizaciones del sector privado nombran un DPO de forma voluntaria por razones de gestión del riesgo. Los DPO a nivel de grupo están permitidos y son habituales en las multinacionales; deben permanecer accesibles para los interesados y para la autoridad de control. ## Official sources - [EUR-Lex, Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [European Data Protection Board](https://www.edpb.europa.eu/) - [CNIL, Guidance and decisions](https://www.cnil.fr/) --- # EBIOS RM vs ISO 27005: el enfrentamiento. **URL:** https://cyberacademy.net/es/resources/pillars/ebios-rm-vs-iso-27005 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition EBIOS Risk Manager es el método nacional francés de evaluación de riesgos publicado por ANSSI, centrado en los escenarios estratégicos de ciberataque. ISO/IEC 27005 es la norma internacional de gestión de riesgos para la seguridad de la información, alineada con ISO 31000 y utilizada como capa metodológica para el trabajo del ISMS según ISO 27001. Ambas son metodologías para profesionales; son más complementarias que alternativas. ## TL;DR - EBIOS RM es estratégico y orientado a escenarios. Vincula los procesos de negocio con los objetivos del atacante y, a partir de ahí, deriva los controles técnicos. Tiene fuerza en el sector público francés y en los operadores de importancia vital. - ISO 27005 es agnóstico en cuanto al método y se combina de forma nativa con el Anexo A de ISO 27001. Es el estándar en las auditorías internacionales. - EBIOS RM produce un número menor de escenarios de alto impacto con una narrativa rica. ISO 27005 produce un registro de riesgos exhaustivo. - Ambas son credenciales acreditadas de PECB: EBIOS Risk Manager (5 días), ISO/IEC 27005 Risk Manager (5 días). Lead Risk Manager solo existe para ISO 31000. - En la práctica: ISO 27005 para el registro de riesgos del ISMS, EBIOS RM como complemento para identificar los escenarios estratégicos que merecen la atención del consejo de administración. ## Full content ## Cómo se ejecuta realmente cada método en un proyecto La división entre ambos métodos no es una cuestión de calidad; es una cuestión de punto de partida. ISO 27005 parte de los activos y las amenazas y avanza hacia fuera hasta un registro de riesgos completo. EBIOS RM parte de aquello que la organización teme perder y retrocede a través del atacante que provocaría esa pérdida. Los dos producen artefactos diferentes porque plantean preguntas de partida distintas, y esa diferencia es lo que percibirán su auditor, su consejo de administración y su plan de proyecto. El trabajo con ISO 27005 es iterativo y exhaustivo por diseño. Se establece el contexto, se identifican los riesgos en todo el alcance, se analizan la probabilidad y la consecuencia, se evalúan frente a los criterios de aceptación y, después, se tratan. El resultado es un registro vivo que se vuelve a ejecutar de forma cíclica. Es el motor de riesgo natural para un ISMS de ISO 27001 porque habla el mismo lenguaje que el sistema de gestión: alcance, criterios, plan de tratamiento, riesgo residual, aprobación. EBIOS RM se ejecuta como cinco talleres con una secuencia definida: encuadre y línea base de seguridad, orígenes del riesgo, escenarios estratégicos, escenarios operativos y tratamiento del riesgo. El método le obliga a nombrar primero los eventos temidos, luego las fuentes de riesgo (quién atacaría y por qué), después las rutas de ataque de alto nivel, antes de tocar un solo control. El curso EBIOS Risk Manager recorre cada taller con entregables reales, de modo que sale capaz de facilitar la secuencia, no solo de describirla. ## EBIOS RM vs ISO 27005 de un vistazo La tabla siguiente es la comparación que la mayoría de los equipos necesita sobre la mesa: no la filosofía, sino en qué se centra cada método, qué le entrega al final y dónde se espera realmente. **EBIOS RM vs ISO 27005: enfoque, resultado y dónde se espera cada uno** | Dimensión | EBIOS RM | ISO 27005 | | --- | --- | --- | | Origen | Método nacional francés, publicado por ANSSI | Norma internacional, ISO/IEC, alineada con ISO 31000 | | Enfoque | Escenarios estratégicos de ataque; intereses de negocio vinculados a las fuentes de amenaza | Identificación sistemática del riesgo de seguridad de la información en todo el alcance | | Punto de partida | Eventos temidos y orígenes del riesgo (de arriba hacia abajo) | Activos, amenazas, vulnerabilidades (de abajo hacia arriba) | | Resultado | Un pequeño conjunto de escenarios narrativos de alto impacto con estrategia de tratamiento | Un registro de riesgos exhaustivo y repetible con plan de tratamiento | | Granularidad | Pocos escenarios, narrativa profunda, legible para el consejo | Muchos riesgos, estructurados, legibles para el ISMS | | Relación con ISO 27001 | Complemento; aporta los riesgos estratégicos al ISMS | Capa metodológica nativa para la Cláusula 6.1.2 y el Anexo A | | Dónde se espera | Sector público francés, OIV/OES, contratación con influencia de ANSSI | Auditorías internacionales, ISMS multinacionales, garantía a clientes | | Credencial acreditada | PECB EBIOS Risk Manager (5 días) | PECB ISO/IEC 27005 Risk Manager (5 días) | ## Cómo se vinculan ambos con ISO 27001 ISO 27001 exige un proceso definido de evaluación y tratamiento del riesgo de seguridad de la información, pero no impone un método específico. Ese único hecho es la razón de que esta comparación exista. La Cláusula 6.1.2 le indica que evalúe el riesgo y elabore una Declaración de Aplicabilidad; no le dice que use ISO 27005 ni ninguna otra cosa. Los auditores comprueban que su proceso sea coherente, repetible y que produzca decisiones de tratamiento defendibles. El método es su elección. ISO 27005 es aquí el camino de menor resistencia porque fue redactado para ser la capa metodológica bajo la norma. Su terminología, su lógica de criterios de aceptación y su estructura de plan de tratamiento encajan directamente en el ISMS sin necesidad de traducción. Si está construyendo o gestionando el sistema de gestión, aprenda el motor que le corresponde: el curso ISO/IEC 27005 Risk Manager cubre el ciclo completo de evaluación y tratamiento, mientras que el curso ISO/IEC 27005 Foundation es el punto de entrada adecuado si necesita los conceptos antes de facilitar. EBIOS RM se vincula con la misma cláusula desde otro ángulo. No reemplaza el registro; afina su parte superior. Los escenarios estratégicos se convierten en el pequeño conjunto de riesgos que justifican el mayor escrutinio en la SoA y en el dosier del consejo. Los equipos que necesitan dominar la metodología de principio a fin, incluida la gobernanza de la evaluación y el papel de liderazgo en toda una organización, cursan ISO/IEC 27005 Lead Risk Manager. > **ISO 27001 no exige ISO 27005** La Cláusula 6.1.2 obliga a un proceso de riesgo, no a un método con nombre propio. Puede ejecutar EBIOS RM, ISO 27005, un método interno o una combinación, siempre que esté documentado, sea repetible y produzca decisiones de tratamiento trazables. Los auditores examinan el proceso, no la marca. ## La decisión: cuál, y cuándo ambos La mayoría de los equipos plantean esto como un dilema de uno u otro y luego se arrepienten. La respuesta honesta es que la cuestión tiene dos capas: qué exige su auditoría o su sector, y qué necesita realmente su panorama de riesgo. Resuélvalas en ese orden. 1. Si entra en juego un comprador con influencia de ANSSI, un contrato público francés o una obligación de OIV/OES, EBIOS RM es el lenguaje esperado. Lidere con él en la capa estratégica. 1. Si su garantía proviene de un certificado internacional de ISO 27001 o de auditorías de clientes multinacionales, ISO 27005 es el método por defecto que el auditor lee con fluidez. 1. Si tiene un problema real de adversario (un objetivo de alto valor, un servicio crítico regulado, riesgo cibernético a nivel de consejo), ejecute EBIOS RM sobre el registro para hacer aflorar los escenarios que merecen escalado. 1. Si no tiene ni un mandato del sector francés ni un perfil de adversario agudo, ISO 27005 por sí solo es suficiente y más económico de operar. Ejecutar ambos no es redundante cuando se delimita correctamente. ISO 27005 le da amplitud: cada riesgo del registro, tratado y seguido. EBIOS RM le da profundidad en los pocos escenarios que realmente harían daño. El error es ejecutar ambos con la misma granularidad, lo que duplica el trabajo y produce dos registros que nadie reconcilia. Use EBIOS RM para seleccionar y narrar; use ISO 27005 para enumerar y seguir. > **Delimite EBIOS RM de forma estrecha a propósito** EBIOS RM resulta más valioso cuando lo dirige a un perímetro reducido y de alto valor: el servicio joya de la corona, la función cuya pérdida es un evento para el consejo. Dirigido a toda la organización se vuelve lento y diluye su propia fuerza. Deje que ISO 27005 cargue con la amplitud y reserve EBIOS RM para los escenarios que justifican una narrativa. ## Errores comunes y la realidad de la sala de auditoría Los fallos son predecibles, y rara vez tienen que ver con el método en sí. - Elegir el método por preferencia en lugar de por audiencia. La pregunta correcta es quién lee el resultado: un comprador público francés espera el vocabulario de EBIOS RM, un auditor de certificación internacional espera un registro con forma de ISO 27005. Elija pensando en el lector. - Tratar los escenarios de EBIOS RM como sustituto de un registro completo. Los escenarios estratégicos son deliberadamente pocos. Un auditor que comprueba la cobertura de ISO 27001 preguntará dónde está documentado el resto del panorama de riesgo, y un puñado de narrativas no es una respuesta. - Ejecutar ISO 27005 como una hoja de cálculo de una sola vez. La norma es iterativa. Un registro fechado hace dieciocho meses sin cadencia de revisión es una observación a punto de producirse. - Confundir las credenciales. No existe Lead Auditor ni Lead Risk Manager para EBIOS RM, y la única credencial de Lead Risk Manager se sitúa bajo ISO 31000, no bajo ISO 27005. Planifique la ruta de certificación de su equipo en función de lo que realmente existe. En la sala de auditoría, la realidad es más simple de lo que el debate sugiere. El auditor de certificación no califica su método frente a un rival; comprueba si el proceso que ha elegido está documentado, se aplica de forma coherente y es trazable desde el riesgo hasta el tratamiento y la aceptación residual. EBIOS RM le ayuda a explicar por qué ciertos riesgos de alto impacto recibieron una atención específica. ISO 27005 le ayuda a demostrar que nada se coló por las grietas. La postura más sólida, para las organizaciones que genuinamente necesitan ambos, es un registro de ISO 27005 como sistema de referencia con los escenarios de EBIOS RM superpuestos para justificar las decisiones que más importaron. ## FAQ ### ¿Cuál espera mi auditor? Para una auditoría de certificación de ISO 27001, el auditor espera por defecto una metodología alineada con ISO/IEC 27005. La revisión de 2022 de ISO 27005 establece de forma explícita un puente con la Cláusula 6 de ISO 27001 y con los principios de ISO 31000. Para las auditorías del sector público francés (HFDS, inspecciones de ANSSI a operadores de importancia vital en el marco de la LPM, supervisión de NIS 2 por parte de ANSSI), EBIOS RM es el lenguaje esperado. No articular los escenarios estratégicos con el vocabulario de EBIOS RM dará lugar a observaciones. ### ¿Puedo usar ambos al mismo tiempo? Sí, y muchas organizaciones lo hacen. EBIOS RM produce de 5 a 10 escenarios estratégicos de ataque con fuentes de amenaza identificadas, activos de negocio y eventos temidos; estos se convierten en las entradas de un registro de riesgos de ISO 27005 que gestiona la capa operativa (combinaciones de vulnerabilidad y activo, puntuación de probabilidad e impacto, opciones de tratamiento). La combinación funciona porque EBIOS RM opera a nivel de escenario (apto para el consejo) mientras que ISO 27005 opera a nivel de activo y control (apto para la auditoría). Vincular ambos exige disciplina, pero es un terreno bien transitado en las entidades francesas sujetas tanto a la supervisión de ANSSI como a la certificación ISO 27001. ### ¿EBIOS RM solo es relevante en Francia? En su mayor parte, sí. Fuera de Francia, ISO 27005 es la lengua franca para la metodología de riesgo del ISMS. EBIOS RM es reconocido por ENISA en algunas publicaciones y se utiliza en jurisdicciones de influencia francesa, pero rara vez lo encontrará en auditorías fuera de Francia o del África francófona. Si su huella de auditoría es puramente internacional, ISO 27005 es la opción única más segura. Si opera en Francia, en el sector público, o vende a entidades del Estado francés, se espera que conozca EBIOS RM. ### ¿Qué cubre la credencial PECB EBIOS Risk Manager? Cinco días. Cubre los cinco talleres de EBIOS RM: alcance y línea base de seguridad, fuentes de riesgo, escenarios estratégicos, escenarios operativos, tratamiento del riesgo. El examen es de libro abierto, de tres horas, con una mezcla de preguntas de opción múltiple y de escenario. La credencial está reconocida por ANSSI a través de la vía de acreditación PECB Gold Partner. No sustituye a ISO/IEC 27005 Risk Manager si su auditor espera la metodología ISO; la complementa. ## Official sources - [ANSSI, EBIOS Risk Manager method](https://cyber.gouv.fr/la-methode-ebios-risk-manager) - [ISO, ISO/IEC 27005:2022](https://www.iso.org/standard/80585.html) --- # El precio real de un ISO 27001 Lead Implementer en Europa. **URL:** https://cyberacademy.net/es/resources/pillars/iso-27001-lead-implementer-price-europe **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition En Europa en 2026, una promoción de ISO 27001 Lead Implementer con instructor cuesta entre 2.800 y 3.200 euros por plaza para una entrega estándar de 5 días, todo incluido (curso, materiales PECB, tasa de certificación, examen, una repetición). La autoformación es un 30% a 40% más barata. Las promociones in-company cuestan de 12.000 a 18.000 euros para hasta 12 alumnos. ## TL;DR - Estándar con instructor (promoción en directo online o presencial), 5 días, todo incluido: 2.800 a 3.200 euros por plaza. La variación procede del nivel del partner y de la ubicación, no del temario. - Autoformación (módulos grabados, materiales oficiales PECB, examen incluido): 1.700 a 2.200 euros. Finalización más lenta, menos preguntas respondidas en directo. - Promoción privada in-company, hasta 12 alumnos, presencial o virtual: 12.000 a 18.000 euros por los 5 días completos. Presupuesto enviado en un día laborable desde la página de formación in-company. - Los partners Gold y Platinum de PECB cobran un 5% a 15% por encima de los niveles inferiores, a cambio de mayor profundidad de acreditación y la garantía de certificación o reembolso cuando aplica. - Vigila el paquete: tasa de formación, tasa de certificación, tasa de examen, repetición, materiales, acompañamiento posterior a la promoción. Las ofertas más baratas suelen separar la tasa de certificación. ## Full content ## Lo que realmente estás comprando La cifra destacada en una página de Lead Implementer rara vez es la cifra que pagas. El curso te enseña a diseñar y operar un Sistema de Gestión de Seguridad de la Información frente a los controles de ISO 27001, pero la partida que decide tu coste real es la credencial de certificación, no la plaza en la sala. Un presupuesto creíble agrupa seis cosas: la impartición de la formación, los materiales oficiales, la tasa de certificación, el examen, al menos una repetición e, idealmente, algo de apoyo posterior a la promoción. Cuando un precio parece bajo, una de esas seis cosas se ha desplazado normalmente fuera de la página hacia una segunda factura que recibes más tarde. La credencial por la que pagas se sitúa un escalón por encima del nivel de fundamentos y un escalón por debajo de la vía de auditoría. Si nunca has trabajado dentro de un ISMS, el curso ISO 27001 Foundation es el punto de entrada más barato y te dice si la vía de implementación es el gasto adecuado o no. Si tu función es evaluar los sistemas de otros en lugar de construir el tuyo, la vía ISO 27001 Lead Auditor es la que conviene presupuestar en su lugar. ## Con instructor, autoformación o in-company: el verdadero compromiso Las tres modalidades de impartición no son tres niveles de calidad. Son tres respuestas a una pregunta distinta: cuánto acceso en directo a un formador necesitas, y a cuántas personas estás certificando a la vez. La modalidad con instructor encaja para un único alumno que quiere que le respondan las preguntas en la sala y una ventana fija de cinco días que obliga a terminar. La autoformación encaja para un alumno disciplinado que cambiará las respuestas en directo por un precio más bajo y un calendario flexible. La modalidad in-company solo tiene sentido cuando ya tienes una promoción, porque la tasa de promoción privada es fija independientemente de si llenas cuatro plazas o doce. **ISO 27001 Lead Implementer en Europa, 2026: modalidad de impartición, banda de precio y qué incluye la banda** | Modalidad de impartición | Banda de precio (EUR) | Qué debería incluir la banda | Más adecuado para | | --- | --- | --- | --- | | Con instructor, 5 días (en directo online o presencial) | 2.800 a 3.200 por plaza | Curso, materiales oficiales, tasa de certificación, examen, una repetición | Un único alumno que quiere respuestas en directo y una ventana fija de finalización | | Autoformación (módulos grabados) | 1.700 a 2.200 por plaza | Módulos grabados, materiales oficiales, examen incluido; menos preguntas respondidas en directo | Un alumno disciplinado que cambia el acceso en directo por un precio más bajo | | Promoción privada in-company (hasta 12 alumnos) | 12.000 a 18.000 en total | 5 días completos para el grupo, presupuestado por promoción y no por plaza | Equipos que certifican a varias personas en el mismo estándar a la vez | Calcula la cifra in-company por cabeza antes de decidir. Una promoción privada en el límite inferior, llena con ocho o más alumnos, queda muy por debajo de la tarifa por plaza con instructor y mantiene la conversación anclada a tus propios sistemas y a tu propia Statement of Applicability. Por debajo de aproximadamente cinco alumnos, la promoción pública por plaza suele ser más barata. ## Los trucos de desagregación que hay que detectar La mayor parte de la confusión de precios en este mercado es deliberada. Un catálogo anuncia una cifra que cubre solo la formación, y luego la tasa de certificación, el examen y los materiales llegan como cargos separados una vez que te has comprometido. El total queda cerca, o por encima, de una promoción todo incluido que parecía más cara en la primera pantalla. Estas son las partidas que hay que confirmar por escrito antes de firmar: - Tasa de certificación: el cargo por la propia credencial, distinto del examen. Es la partida que con más frecuencia se desplaza fuera del precio destacado. - Tasa de examen y repetición: confirma que el examen está incluido y que se cubre al menos una repetición. Una repetición comprada por separado rara vez es barata. - Materiales oficiales: el material de curso con licencia, no una exportación de diapositivas. Si la página es vaga sobre el origen, pregunta. - Apoyo posterior a la promoción: acompañamiento o acceso al formador tras los cinco días. A menudo se suprime de las ofertas baratas, y a menudo es la parte más útil para quien implementa por primera vez. > **Lee la línea de certificación antes que la línea de precio** Si un presupuesto no nombra la tasa de certificación como una partida separada e incluida, asume que está excluida y pregunta. La diferencia entre "curso" y "curso más certificación" es la mayor fuente de facturas sorpresa en este mercado, y es la más fácil de resolver antes de firmar. ## Cómo negociar el presupuesto corporativo Los precios públicos por plaza tienen poco margen de movimiento; el nivel del partner y la ubicación fijan la banda, no tu regateo. La palanca está en el presupuesto in-company, donde la tasa es fija y el coste marginal de un alumno adicional es casi cero para el proveedor. Los movimientos que realmente cambian una cifra corporativa: 1. Llena la sala. La tasa de promoción es la misma para cuatro plazas o doce, así que cada plaza por encima del punto de equilibrio reduce tu coste efectivo por cabeza. Forma el grupo antes de pedir un descuento. 1. Agrupa los niveles. Si una parte del equipo necesita fundamentos y otra necesita la credencial de implementador, pide ambos en un solo presupuesto. Las promociones de nivel mixto son más fáciles de descontar que un único curso aislado. 1. Comprométete con una fecha. Un proveedor pone mejor precio a una franja de calendario confirmada que a un quizás. Aportar una ventana fija y un número de asistentes confirmado vale más que pedir un porcentaje de descuento. 1. Pregunta qué es prescindible, no solo qué es más barato. Si ya dispones de los materiales o solo necesitas certificar a una parte del equipo, un proveedor puede redimensionar el paquete en lugar de descontarlo. Cuando la promoción está formada y la fecha fijada, la página in-company de ISO 27001 Lead Implementer devuelve un presupuesto por promoción en un día laborable, que es la cifra contra la que negocias, no la tarifa pública por plaza. ## Por qué el nivel del partner cuesta más, y cuándo merece la pena Los partners Gold y Platinum de PECB cobran por encima de los niveles inferiores, y la prima no es arbitraria. Compra profundidad de acreditación, formadores con más experiencia y, cuando un proveedor la ofrece, una garantía de certificación o reembolso. Para quien implementa por primera vez y tiene que salir con un ISMS en funcionamiento y un examen aprobado, esa prima a menudo se amortiza con una sola repetición evitada y el acceso posterior a la promoción que la acompaña. Para un profesional experimentado que renueva una credencial, el nivel inferior suele bastar. > **Pon precio al resultado, no a la plaza** La promoción más barata solo es barata si apruebas y si realmente puedes construir el ISMS después. Sopesa el precio con instructor todo incluido frente a una oferta barata de autoformación más una probable repetición más las horas de consultoría que comprarás después para compensar el apoyo que no recibiste. La cifra destacada más baja pierde con frecuencia esa comparación. ## La decisión, en una sola pasada Parte del número de asistentes. Un alumno que necesita respuestas en directo: con instructor, todo incluido, 2.800 a 3.200 euros, tasa de certificación confirmada por escrito. Un alumno disciplinado con presupuesto ajustado: autoformación a 1.700 a 2.200, aceptando una finalización más lenta y menos respuestas en directo. Un equipo de cinco o más en el mismo estándar: in-company a 12.000 a 18.000 por la promoción, haz el cálculo por cabeza, llena la sala y negocia el paquete en lugar de la plaza. En todos los casos, el número que decide tu coste real es si la tasa de certificación está dentro del presupuesto o esperando en una segunda factura. ## FAQ ### ¿Por qué el precio no aparece en cada catálogo? La mayoría de los proveedores de formación recurren por defecto a "desde" o "contacta para un presupuesto" para controlar su margen de negociación. La contrapartida es fricción: los compradores individuales se marchan, los compradores corporativos esperan días por una cifra, y los precios se separan para una misma promoción. Cyber Academy publica el precio estándar en cada página de curso del catálogo; el flujo de presupuesto se reserva para los ámbitos in-company y de varias plazas, donde una propuesta a medida resulta realmente útil. ### ¿Qué debe incluir el paquete? Un paquete limpio de ISO 27001 Lead Implementer en Europa contiene: la tasa de formación de 5 días, los materiales oficiales del curso PECB (digital e impreso), la tasa de certificación pagada a PECB, el primer intento de examen, una repetición gratuita y la vigencia de la credencial (sin tasa de renovación para la propia credencial de Lead Implementer). Omisiones habituales en las ofertas más baratas: la tasa de certificación (añadida después como "nosotros impartimos la formación, PECB emite la credencial por separado"), la repetición (cobrada a 200 a 400 euros) o los materiales oficiales (vendidos como kit aparte). ### ¿Cómo funciona el precio in-company? Las promociones in-company se cobran por promoción y no por plaza. Una promoción estándar de Lead Implementer de 5 días para hasta 12 alumnos cuesta de 12.000 a 18.000 euros en Europa en 2026. El precio cubre el tiempo del formador, los materiales oficiales PECB para cada alumno, la tasa de certificación de cada alumno y el examen de cada alumno. Variables que mueven el precio: ubicación (desplazamiento presencial), calendario (bloque único frente a sesiones partidas), idioma (inglés por defecto, otros idiomas bajo petición), adaptación sectorial (ejemplos y ejercicios ajustados al contexto del comprador) y la veteranía del formador solicitado. ### ¿Merece la pena la promoción más barata? A menudo no. La parte baja del mercado europeo (1.500 a 2.200 euros con instructor, examen incluido) suele ser: formador junior, promoción grande (15 a 25 alumnos), acompañamiento previo al examen escaso, seguimiento posterior limitado. La certificación que recibes es la misma; la probabilidad de aprobar al primer intento es notablemente menor, y la transferencia de conocimiento operativo es desigual. Nuestra tasa de aprobado al primer intento del 99,1% en promociones PECB con instructor se debe en parte al equipo de formadores y en parte al tamaño de la promoción (10 a 15, nunca por encima). Ambos tienen un coste. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer training course](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) --- # ISO 31000: Foundation → Risk Manager → Lead Risk Manager. **URL:** https://cyberacademy.net/es/resources/pillars/iso-31000-foundation-risk-manager-lead-risk-manager **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 31000 es la norma internacional de orientación para la gestión de riesgos: principios, marco y proceso, aplicable a cualquier organización y a cualquier tipo de riesgo. No es certificable; el recorrido de PECB es Foundation, Risk Manager y, después, Lead Risk Manager. No existe el ISO 31000 Lead Auditor: ISO 31000 es una guía, no una norma de sistema de gestión, por lo que no hay nada contra lo que auditar. ## TL;DR - ISO 31000 es una guía, no un sistema de gestión certificable. No existe el Lead Auditor. - Recorrido de PECB: Foundation (2 días), Risk Manager (5 días), Lead Risk Manager (5 días). La credencial sénior es Lead Risk Manager. - Foundation aporta el vocabulario, los principios y el modelo de proceso. Es un requisito previo obligatorio para las credenciales sénior. - Risk Manager aplica ISO 31000 a un alcance concreto. Lead Risk Manager dirige el programa de riesgos empresariales en todas las funciones. - Complementa a ISO 27005 (riesgo específico de la seguridad de la información) y a EBIOS RM (escenarios cibernéticos estratégicos): distintas perspectivas sobre la misma disciplina de riesgo. ## Full content ## Cómo funciona realmente el recorrido de ISO 31000 en una organización ISO 31000 no es algo que se implante como se implanta un sistema de gestión. No hay Statement of Applicability, ni cláusulas obligatorias que satisfacer, ni ciclo de auditoría de seguimiento. Lo que se construye en su lugar es un marco de gestión de riesgos: una forma de identificar, analizar, tratar, supervisar y reportar el riesgo de manera coherente en toda la organización, y un proceso que las personas con funciones operativas siguen de verdad. La norma le aporta los principios y el vocabulario; el trabajo consiste en hacerlos reales en su gobernanza, sus comités y sus puntos de decisión. Por eso el recorrido se desarrolla como lo hace. Foundation le aporta el lenguaje compartido para que "probabilidad", "criterios de riesgo", "apetito de riesgo" y "riesgo residual" signifiquen lo mismo para todos los que están en la sala. Risk Manager le enseña a ejecutar el proceso dentro de un alcance definido: un departamento, un programa, una línea de producto. Lead Risk Manager le enseña a diseñar y dirigir el propio marco entre las funciones, lo que es un trabajo de gobernanza tanto como técnico. El recorrido es secuencial por diseño. Foundation es el requisito previo para las credenciales sénior, por lo que la mayoría de los profesionales empiezan con el curso ISO 31000 Foundation antes de decidir si necesitan el nivel Risk Manager o Lead Risk Manager. ## Elegir su nivel: Risk Manager o Lead Risk Manager La decisión no tiene que ver con la jerarquía sobre el papel, sino con aquello de lo que será responsable. Risk Manager es para la persona que ejecuta el proceso de riesgo dentro de un alcance y es propietaria de un registro de riesgos: facilita talleres, puntúa los riesgos según criterios acordados, propone tratamientos y mantiene el registro fiable a lo largo del tiempo. Lead Risk Manager es para la persona que tiene que dar coherencia al conjunto en toda la organización: definir los criterios y el apetito de riesgo, diseñar el marco, integrarlo con la estrategia y con las demás funciones de aseguramiento, y reportar al consejo. Una prueba útil: si su trabajo es responder "cuáles son nuestros principales riesgos en esta área y qué estamos haciendo al respecto", Risk Manager es el nivel adecuado. Si su trabajo es responder "es nuestro marco de gestión de riesgos adecuado para su propósito, y puede la dirección confiar en él para tomar decisiones", necesita Lead Risk Manager. Muchas personas cursan primero Risk Manager, gestionan un programa durante uno o dos años y luego cursan Lead Risk Manager cuando pasan a un puesto empresarial o cercano al de CISO. **Recorrido de PECB para ISO 31000: nivel, alcance y a quién se adapta** | Nivel | Duración | Alcance | A quién se adapta | | --- | --- | --- | --- | | Foundation | 2 días | Principios, marco y modelo de proceso; solo vocabulario, sin responsabilidad de implementación | Cualquiera que necesite el lenguaje compartido: analistas, jefes de proyecto, auditores de otros ámbitos, recién llegados al riesgo | | Risk Manager | 5 días | Aplicar el proceso de ISO 31000 dentro de un alcance definido; ser propietario y gestionar un registro de riesgos | Profesionales que facilitan evaluaciones y gestionan el riesgo de un departamento, programa o producto | | Lead Risk Manager | 5 días | Diseñar y dirigir el marco de riesgo empresarial; fijar criterios y apetito; reportar a la dirección | Responsables de riesgo, CISOs y puestos sénior de GRC responsables de todo el programa | ## Por qué no existe el ISO 31000 Lead Auditor Esta pregunta surge constantemente porque la mayoría de las demás credenciales ISO vienen en parejas: Lead Implementer y Lead Auditor, en correspondencia con la norma certificable que tienen detrás. ISO 31000 no tiene Lead Auditor porque no hay nada contra lo que auditar. Una auditoría comprueba la conformidad con requisitos, las declaraciones "shall" de una norma de sistema de gestión como ISO 27001 o ISO 9001. ISO 31000 contiene orientación, el "should" de las buenas prácticas, no requisitos. No se puede certificar a una organización conforme a ISO 31000, por lo que no se puede ejecutar una auditoría de certificación contra ella, por lo que no existe una credencial de auditor. Eso no significa que la gestión de riesgos escape al aseguramiento. Se evalúa de forma indirecta. Cuando un auditor de ISO 27001 examina su proceso de evaluación y tratamiento de riesgos, está comprobando la conformidad con las cláusulas 6.1 y 8.2/8.3 de ISO 27001, e ISO 31000 (a menudo a través de ISO 27005) es la referencia reconocida sobre cómo debería ser ese proceso. Así, el Lead Risk Manager construye el marco, y el auditor del sistema de gestión comprueba si el marco se aplica allí donde una norma certificable lo exige. Son dos trabajos distintos, y confundirlos es el malentendido más habitual que la gente trae a la sala de formación. > **La realidad de la sala de auditoría** En una auditoría de ISO 27001, nadie pregunta "está usted certificado conforme a ISO 31000". Piden ver sus criterios de riesgo, los resultados de su evaluación de riesgos, su plan de tratamiento de riesgos y la evidencia de que lo ha revisado. Un marco limpio basado en ISO 31000 hace que esa parte de la auditoría sea breve. Un marco que existe únicamente como documento de política, con un registro que nadie ha tocado en un año, es de donde salen las no conformidades. ## Cómo complementa ISO 31000 a ISO 27005 y EBIOS RM No son normas que compitan entre sí; son distintas perspectivas sobre la misma disciplina, y los profesionales sénior las usan juntas. ISO 31000 es el marco genérico que se aplica a cualquier riesgo en cualquier organización. ISO 27005 estrecha ese marco al riesgo de seguridad de la información, con el detalle de activos, amenazas y vulnerabilidades que necesita un ISMS. EBIOS Risk Manager, el método francés (ANSSI), aborda el problema desde escenarios de ataque estratégicos y el ecosistema de atacantes y partes interesadas, lo que resulta sólido para el riesgo cibernético de alto impacto y cada vez más esperado en los sectores públicos y regulados de la UE. El patrón práctico es por capas: ISO 31000 fija los principios, el marco y el proceso que comparte toda la organización; ISO 27005 Risk Manager le aporta el método específico de seguridad de la información que se acopla a un ISMS conforme a ISO 27001; y EBIOS Risk Manager le aporta la visión basada en escenarios y centrada en el atacante para los riesgos cibernéticos más importantes. No se contradicen entre sí, y el vocabulario de ISO 31000 es lo que permite a un equipo moverse entre ellos sin confusión. **ISO 31000 frente a ISO 27005 frente a EBIOS RM** | | ISO 31000 | ISO 27005 | EBIOS RM | | --- | --- | --- | --- | | Alcance | Cualquier riesgo, cualquier organización | Riesgo de seguridad de la información | Escenarios de riesgo cibernético estratégico | | Función | Principios, marco, proceso | Método de riesgo específico de SI para un ISMS | Análisis impulsado por el atacante y el ecosistema | | Se combina con | Gobernanza empresarial | Certificación ISO 27001 | ANSSI / sector regulado y público | | Enfoque | Genérico y descendente | Activo, amenaza, vulnerabilidad | Impulsado por escenarios y partes interesadas | ## Relevancia más allá de lo cibernético, y los errores habituales Como ISO 31000 es independiente del tipo de riesgo, el mismo marco cubre el riesgo operativo, financiero, de cadena de suministro, de proyectos, de seguridad, de cumplimiento y estratégico. Ese es su verdadero valor para un CISO que quiere un asiento en la mesa empresarial: hablar ISO 31000 significa hablar el lenguaje que el consejo y la función de riesgo más amplia ya utilizan, no un dialecto cibernético que tengan que traducir. La credencial viaja bien fuera de la seguridad, lo cual es parte de por qué se sitúa en el centro de una carrera seria de GRC y no en su periferia. Los errores son consistentes entre organizaciones. La gente trata el registro de riesgos como un artefacto de cumplimiento que se produce una vez al año en lugar de como una herramienta viva de decisión. Definen criterios de riesgo con los que nadie está de acuerdo, de modo que la puntuación se convierte en teatro. Confunden el apetito de riesgo (una decisión de la dirección) con la tolerancia al riesgo (el rango operativo), y no fijan ninguno de los dos de forma explícita, lo que significa que las decisiones de tratamiento no tienen anclaje. Y se saltan Foundation, metiendo a todo un equipo en un curso de Risk Manager donde la mitad de la sala todavía discute qué significa "probabilidad". Si está construyendo un programa en lugar de simplemente presentarse a un examen, el orden que funciona es: pasar al equipo por ISO 31000 Foundation para tener un vocabulario compartido, pasar a los responsables de su alcance por ISO 31000 Risk Manager, y hacer que quien sea propietario del marco empresarial curse ISO 31000 Lead Risk Manager. Esa secuencia evita el modo de fallo más costoso, que es un marco que solo una persona entiende. > **Fije el apetito antes de puntuar** No empiece a puntuar riesgos hasta que la dirección haya acordado los criterios de riesgo y haya declarado un apetito, aunque sea aproximado. Sin ese anclaje, cada puntuación de riesgo es una opinión privada y sus decisiones de tratamiento no se pueden defender. Lead Risk Manager existe en gran medida para acertar en este paso. ## FAQ ### ¿Por qué no existe el ISO 31000 Lead Auditor? ISO 31000 es una guía, no una norma de sistema de gestión. No hay un sistema certificable contra el que auditar. Algunos catálogos de formación anuncian un ISO 31000 Lead Auditor; esa credencial no existe dentro del programa de PECB. Quienes la solicitan suelen referirse al ISO 27001 Lead Auditor (que audita el ISMS empleando la metodología de riesgo de ISO 27005) o al ISO/IEC 27005 Risk Manager (que aplica la metodología a la seguridad de la información). Si su auditor espera una auditoría de ISO 31000, replíquele: no existe un criterio de conformidad certificable. Lo más probable es que se refiera a una evaluación de madurez del marco de gestión de riesgos, que es un ejercicio diferente. ### Risk Manager o Lead Risk Manager, ¿cuál es el adecuado para mí? Risk Manager (5 días) está dirigido a profesionales que gestionan un alcance de riesgo definido: un departamento, un programa, una filial. El curso le enseña a operar ISO 31000 dentro de ese alcance. La mayoría de los analistas de GRC y responsables de riesgo se quedan en este nivel. Lead Risk Manager (5 días) está dirigido a profesionales sénior que gestionan el programa de riesgos empresariales: definir el apetito de riesgo, diseñar el marco, integrar el riesgo entre las unidades de negocio y reportar al consejo. Es obligatorio cuando el cargo es Head of Risk, Chief Risk Officer o equivalente. ### ¿Cómo se relaciona ISO 31000 con ISO 27005? Distintos alcances. ISO 31000 es la orientación genérica de gestión de riesgos: se aplica al riesgo financiero, operativo, estratégico, de cumplimiento, de seguridad de la información, a cualquier cosa. ISO 27005 es la aplicación de los principios de ISO 31000 específicamente al riesgo de seguridad de la información en el contexto de un ISMS conforme a ISO 27001. Un profesional de riesgo con credenciales de ISO 31000 opera en toda la empresa. Un especialista en riesgo de seguridad de la información con credenciales de ISO 27005 opera dentro del alcance del ISMS. Los profesionales sénior suelen tener ambas. ### ¿Es ISO 31000 relevante fuera de la ciberseguridad? Sí, mucho. ISO 31000 es independiente del sector. Se utiliza en la gestión del riesgo financiero (junto a los marcos de Basilea y Solvencia), en la gestión del riesgo empresarial (junto a COSO ERM), en el riesgo de la cadena de suministro, el riesgo ambiental, el riesgo de proyectos y el riesgo operativo. Los principios y el modelo de proceso son idénticos en todos los ámbitos; solo cambian las categorías de activos y amenazas. ## Official sources - [ISO, ISO 31000:2018 Risk management](https://www.iso.org/iso-31000-risk-management.html) - [PECB, ISO 31000 Risk Manager](https://pecb.com/en/education-and-certification-for-individuals/iso-31000) --- # CISO vs DPO vs RSSI: quién hace qué, en realidad. **URL:** https://cyberacademy.net/es/resources/pillars/ciso-dpo-rssi **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition El CISO (Chief Information Security Officer) es responsable de la estrategia y el programa de seguridad de la información. El DPO (Data Protection Officer) es responsable de la supervisión independiente, exigida por el GDPR, del tratamiento de datos personales. El RSSI (Responsable de la Sécurité des Systèmes d'Information) es el equivalente francés del CISO. Las tres funciones se solapan en el perímetro de la seguridad de los datos, pero responden a mandatos distintos: el CISO y el RSSI ante la dirección ejecutiva, el DPO ante el regulador. ## TL;DR - El CISO y el RSSI son la misma función con un vocabulario diferente. RSSI es el título francés; CISO es el título internacional. Mismo alcance. - El DPO es independiente por diseño del GDPR, reporta al máximo nivel directivo, no puede ser destituido por desempeñar su función y es el punto de contacto de la autoridad de control. - Responsabilidad del CISO/RSSI: estrategia de seguridad de la información, registro de riesgos, respuesta a incidentes, reporte al consejo. Mandato de la dirección ejecutiva. - Responsabilidad del DPO: supervisión del cumplimiento del GDPR, revisión de la DPIA, derechos de los interesados, diálogo con la autoridad de control. Mandato de la regulación. - Se solapan en la seguridad de los datos (Artículo 32 del GDPR) y en la respuesta a incidentes. Una misma persona no debería ocupar ambas funciones en organizaciones de tamaño significativo: el DPO debe mantenerse independiente de las decisiones de tratamiento de datos que opera el CISO. ## Full content ## Dos responsabilidades, un mismo perímetro La confusión entre estas funciones no es una cuestión de títulos. Es una cuestión de ante qué autoridad responde cada persona. El CISO y el RSSI dirigen un programa en nombre de la dirección ejecutiva: se les juzga por si la organización es lo bastante segura para seguir operando y por si el consejo entiende el riesgo residual que está asumiendo. El DPO responde ante un señor totalmente distinto. La función existe porque el GDPR situó una función de cumplimiento independiente dentro de la organización, y esa función reporta al máximo nivel directivo manteniéndose al margen de las decisiones operativas que debe evaluar. Un lado optimiza para el negocio. El otro lado tiene que poder decirle al negocio que se equivoca. En términos operativos, el CISO y el RSSI construyen y defienden; el DPO revisa y cuestiona. Cuando un equipo de marketing quiere enriquecer una base de datos de clientes con datos de terceros, el CISO pregunta si puede hacerse de forma segura y el DPO pregunta si debe hacerse en absoluto a la luz de los criterios de licitud, minimización y limitación de la finalidad. Ambas preguntas son legítimas. No son la misma pregunta, y en el momento en que las concentra en una sola persona pierde la segunda. ## La comparación que de verdad importa La mayoría de las comparaciones publicadas se quedan en las definiciones. La distinción que resuelve las disputas de organigrama es la línea de reporte y la fuente del mandato, porque es lo que determina quién puede imponerse a quién y quién asume la responsabilidad cuando algo sale mal. **CISO vs DPO vs RSSI: mandato, línea de reporte y certificaciones de señalización** | Dimensión | CISO | DPO | RSSI | | --- | --- | --- | --- | | Mandato principal | Estrategia y programa de seguridad de la información | Supervisión independiente del tratamiento de datos personales | Igual que el CISO (título francés) | | Fuente de autoridad | Delegada por la dirección ejecutiva | Exigida y protegida por el GDPR | Delegada por la dirección ejecutiva | | Reporta a | CEO, consejo o comité de riesgos | Máximo nivel directivo, con independencia | Direction générale o DSI | | Responsable de | Registro de riesgos, controles, respuesta a incidentes, reporte al consejo | Revisión de la DPIA, derechos de los interesados, registro de actividades de tratamiento, diálogo con la autoridad de control | Mismo alcance que el CISO, en el contexto regulatorio francés | | ¿Puede ser destituido por hacer su trabajo? | Sí, como cualquier directivo | No, protegido frente a la destitución por desempeñar su función | Sí, como cualquier directivo | | Certificaciones de señalización | CISM, PECB CCISO, Lead Cybersecurity Manager, CRISC | GDPR DPO, CDPSE, ISO 27701 Lead Implementer | Igual que el CISO, a menudo más ISO 27001 del mercado francés | La columna de certificaciones es la señal práctica que lee un responsable de selección. Un perfil de líder de seguridad se construye sobre CISM para la credencial de nivel directivo, el PECB Certified CISO para el encuadre ejecutivo y Lead Cybersecurity Manager para la construcción del programa. Un perfil de protección de datos señaliza a través de la credencial Certified Data Protection Officer y de una capa de ingeniería de privacidad como CDPSE. Las dos pilas no son intercambiables, y un currículum que las mezcla sin una función principal clara suele señalar a alguien que no ha hecho ninguna de las dos en profundidad. ## Dónde se solapan de verdad: el Artículo 32 y los incidentes El solapamiento es real, y fingir lo contrario es la forma en que las organizaciones acaban con brechas. El Artículo 32 del GDPR exige medidas técnicas y organizativas apropiadas para proteger los datos personales: cifrado, resiliencia, capacidad de restaurar la disponibilidad y pruebas periódicas de esas medidas. Eso es trabajo de seguridad. El CISO es responsable de los controles que lo materializan. Pero el DPO tiene que poder evaluar si esas medidas son apropiadas en relación con el riesgo para los interesados, que es una lente distinta de lo apropiado para el negocio. La forma limpia de gestionarlo: el CISO es responsable de implementar y operar las medidas del Artículo 32, y el DPO es responsable de formar una opinión independiente sobre su adecuación. El CISO construye el estándar de cifrado en reposo; el DPO hace constar en la DPIA que es suficiente para el tratamiento en cuestión, o advierte de que no lo es. Ninguno aprueba su propio trabajo. ISO 27701 se sitúa exactamente en esta costura. Extiende un ISMS ISO 27001 a un sistema de gestión de la información de privacidad, lo que da al CISO y al DPO un marco de controles compartido en lugar de dos vocabularios desconectados. El curso ISO 27701 Lead Implementer es la cualificación más útil para la persona que tiene que lograr que el programa de seguridad y el programa de privacidad se entiendan entre sí. La respuesta a incidentes es el segundo solapamiento y el que se rompe bajo presión. El CISO dirige la respuesta técnica: contener, erradicar, recuperar. El DPO gestiona el reloj regulatorio: el GDPR concede 72 horas para notificar a la autoridad de control una violación de datos personales, y esa evaluación (¿es una violación, es notificable, hay riesgo para los interesados?) es decisión del DPO, no del CISO. Si estas dos personas no están en la misma sala durante la primera hora de un incidente grave, o bien notificará en exceso y quemará credibilidad ante el regulador, o bien notificará de menos e incumplirá el plazo. > **Un solo manual de incidentes, no dos** El fallo más común es un plan de respuesta a incidentes de seguridad que nunca menciona al DPO y un procedimiento de violación de privacidad que nunca menciona la contención. Fusiónelos. El disparador que avisa al CISO también debe avisar al DPO, con un punto de decisión definido sobre la notificabilidad de la violación antes de que empiece a correr el plazo de 72 horas. ## Por qué una sola persona no debería ocupar el CISO y el DPO La razón es estructural, no de carga de trabajo. El GDPR exige que el DPO esté libre de cualquier conflicto de interés: el DPO no puede ocupar un puesto que implique determinar los fines y medios del tratamiento de datos personales. Un CISO hace exactamente eso. El CISO decide qué registros (logs) se conservan, cuánto viven las copias de seguridad, qué supervisión inspecciona el tráfico de los empleados, qué proveedores tratan los datos. Esas son decisiones de tratamiento. Una sola persona que toma esas decisiones y que se supone que debe auditarlas de forma independiente no puede desempeñar el segundo trabajo, porque la autoridad de control no aceptará la autorrevisión como supervisión independiente. Esto no es una opinión de Cyber Academy. Las autoridades de control europeas ya han sancionado a organizaciones por nombrar a un DPO que además ocupaba una función operativa sobre el tratamiento que se suponía debía supervisar. En una organización pequeña puede que de verdad tenga una sola persona capaz que podría hacer ambas cosas. La respuesta ahí no es combinar las funciones; es hacer de esa persona el CISO y nombrar un DPO externo, o viceversa. Un DPO externo es una solución reconocida y a menudo más limpia, precisamente porque la independencia viene incorporada. > **El patrón para organizaciones pequeñas que aguanta** Por debajo del tamaño de plantilla que justifica un DPO dedicado, mantenga el liderazgo de seguridad interno y contrate la función de DPO a un proveedor externo. Obtiene la independencia protegida que quiere el GDPR, el CISO conserva plena autoridad operativa y dispone de una separación documentada que sobrevive a una auditoría. ## La realidad de la sala de auditoría Cuando un auditor de ISO 27001 o una autoridad de control examina esto, está comprobando una sola cosa: si puede demostrar que las decisiones de seguridad y las decisiones de privacidad fueron tomadas por personas con la autoridad correcta y la independencia correcta. Las evidencias que quieren son mundanas y específicas. 1. Una RACI o equivalente que nombre quién es responsable del registro de riesgos frente al registro de actividades de tratamiento, sin que ninguna persona ocupe a la vez el rol de operar y el de supervisar para un mismo control. 1. Registros de incidentes que muestren que se involucró al DPO en la notificabilidad y al CISO en la contención, con marcas de tiempo que encajen dentro del plazo de 72 horas. 1. DPIAs que recojan una opinión independiente del DPO sobre las medidas de seguridad, no un visto bueno de seguridad reetiquetado como revisión de privacidad. Las competencias de auditoría y aseguramiento que hacen demostrable todo esto pertenecen, de nuevo, a un perfil distinto. CISA construye la disciplina de auditoría y de evidencias, y CRISC construye el lenguaje de cuantificación de riesgos que permite al CISO presentar el riesgo residual al consejo en términos sobre los que este pueda decidir realmente. Estas son las credenciales que convierten una estructura defendible en una demostrable. ## Errores comunes que conviene evitar - Tratar el CISO y el RSSI como dos funciones que deben cubrirse por separado. Son la misma función; el título sigue al idioma y al contexto regulatorio, no al alcance. - Dejar que el DPO reporte al CISO o a la función de TI. Eso destruye la independencia que exige el GDPR y es un hallazgo fácil para cualquier regulador. - Suponer que gana la certificación de mayor rango. Quien posee un CISM no está por ello cualificado como DPO, y una credencial sólida de DPO no convierte a alguien en líder de seguridad. Ajuste la credencial al mandato. - Redactar un informe para el consejo que mezcle el riesgo de seguridad y el riesgo de privacidad en una sola cifra. El consejo necesita ver ambos, porque las consecuencias y las autoridades implicadas son diferentes. Las organizaciones que aciertan en esto no tienen más plantilla que las que se equivocan. Tienen una respuesta clara a una única pregunta: para cualquier decisión sobre datos personales, quién la construye y quién la juzga de forma independiente. Mantenga esas dos respuestas en dos personas distintas, dé a cada una la credencial que corresponde a su mandato, y el organigrama dejará de ser una fuente de hallazgos de auditoría. ## FAQ ### ¿Puede la misma persona ser CISO y DPO? Técnicamente sí en organizaciones pequeñas, pero el EDPB lo desaconseja firmemente. El DPO debe mantenerse independiente de las decisiones de tratamiento; el CISO opera esas decisiones. En una organización pequeña donde la misma persona toma la decisión, la independencia es ficticia. En cualquier organización de tamaño relevante (más de 50 empleados que tratan un volumen significativo de datos personales), separe las funciones. El DPO puede situarse en el equipo jurídico, en el equipo de riesgos o reportar directamente al CEO. El CISO se sitúa en la organización de tecnología o de seguridad. ### ¿Qué certificaciones señalan a un CISO? CISM (ISACA) es la credencial más habitual en el currículum de un CISO: alrededor del 60% de las ofertas de CISO en Europa la solicitan. ISO 27001 Lead Implementer o Lead Auditor (PECB) es la siguiente más común. CISSP es la alternativa tradicional de estilo estadounidense. Para los puestos de RSSI en Francia, las cualificaciones reconocidas por la ANSSI (EBIOS Risk Manager, cualificaciones a través de los programas SecNumCloud o PASSI) tienen peso, además de las credenciales internacionales o en lugar de ellas. ### ¿Qué certificaciones señalan a un DPO? El Certified Data Protection Officer (CDPO, emitido por PECB, alineado con el GDPR) es la referencia europea. El CIPP/E (IAPP) es la credencial internacional alternativa de privacidad, especialmente reconocida en empresas con presencia en Estados Unidos. Para los DPO técnicos (ingenieros de privacidad que operan dentro del equipo de seguridad o junto a él), CDPSE (ISACA) es el complemento técnico. ISO/IEC 27701 Lead Implementer (PECB) es la credencial de sistema de gestión para las organizaciones que operan un ISMS de privacidad. ### ¿Cómo se comparan sus salarios en Europa? Gran variación según el país y el sector. En Francia, en 2026, un CISO/RSSI con experiencia en una empresa del CAC 40 percibe entre 130.000 y 220.000 euros de salario base. Un DPO con experiencia en la misma empresa percibe entre 90.000 y 150.000 euros de salario base. En servicios financieros, ambas funciones tienden a situarse entre un 20% y un 30% por encima. En el segmento medio del mercado, ambas funciones tienden a situarse entre un 30% y un 40% por debajo. La horquilla salarial refleja el alcance: el CISO/RSSI gestiona presupuesto, plantilla y decisiones tecnológicas. El DPO gestiona la supervisión, la independencia y el contacto regulatorio. ## Official sources - [EDPB, Guidelines on Data Protection Officers](https://www.edpb.europa.eu/) - [ANSSI, Référentiel d'exigences pour les RSSI](https://cyber.gouv.fr/) --- # ENCYCLOPEDIA ## AI Risk Manager **URL:** https://cyberacademy.net/es/resources/encyclopedia/ai-risk-manager **Last reviewed:** 2026-06-24 AI Risk Manager es la credencial (PECB / ISACA en desarrollo) para profesionales que gestionan programas de riesgo específicos de IA: riesgo de modelos, sesgo, deriva, transparencia y riesgo de modelos de terceros. Capa operativa que complementa ISO 42001 (nivel de sistema) y el AI Act (capa regulatoria). Acompañante habitual del CISO o del Lead AI Auditor. AI Risk Manager es el rol operativo y la credencial emergente para las personas que dirigen en el día a día el programa de riesgos de IA de una organización. Allí donde ISO 42001 establece el sistema de gestión y el EU AI Act fija el suelo legal, el AI Risk Manager es quien convierte esos marcos en un registro operativo: identificar dónde puede fallar un modelo, decidir qué controles colocar a su alrededor y reportar el riesgo residual a la dirección. Es el primo específico de IA del responsable de riesgos de seguridad de la información, y toma la mayor parte de su método de la gestión de riesgos clásica, añadiendo los modos de fallo propios del aprendizaje automático. ## Lo que el rol abarca realmente El riesgo de TI tradicional se pregunta si un sistema está disponible, es confidencial y mantiene la integridad. El riesgo de IA conserva todo eso y añade una capa de preguntas que los controles convencionales nunca tuvieron que responder. Un AI Risk Manager trabaja a lo largo del ciclo de vida del modelo y normalmente asume las siguientes familias de riesgo. - Riesgo de modelo: el modelo se equivoca de formas difíciles de ver, funciona bien en pruebas pero mal con entradas reales, o falla silenciosamente en casos límite. - Sesgo y equidad: el modelo produce resultados sistemáticamente peores para algunos grupos, a menudo heredados de los datos de entrenamiento. - Deriva: los datos de entrada o el mundo real cambian tras el despliegue, de modo que la precisión se degrada con el tiempo y el modelo necesita monitorización y disparadores de reentrenamiento. - Transparencia y explicabilidad: las partes interesadas, los auditores o los reguladores necesitan entender cómo se llegó a una decisión, especialmente en casos de uso de alto impacto. - Riesgo de modelos de terceros y de cadena de suministro: modelos fundacionales, API y conjuntos de datos que no construiste pero de los que eres responsable. ## Dónde se sitúa respecto a ISO 42001 y la AI Act La forma más clara de ubicar el rol es por capas. La AI Act es la capa regulatoria que indica qué obligaciones aplican a cada nivel de riesgo. ISO 42001 es la capa del sistema de gestión que aporta la estructura de gobernanza, la rendición de cuentas y el ciclo de mejora continua para cumplir esas obligaciones. El AI Risk Manager es la capa operativa que está por debajo de ambas, realizando el trabajo recurrente de evaluación que alimenta de evidencias al AIMS y demuestra que las obligaciones de alto riesgo se cumplen en la práctica. Por eso el rol suele ser complemento, y no sustituto, de un CISO o un Lead AI Auditor. **Las capas de gobernanza de la IA y el papel del AI Risk Manager** | Capa | Artefacto | Pregunta que responde | | --- | --- | --- | | Regulatoria | EU AI Act | ¿Qué obligaciones legales aplican a este sistema de IA? | | Sistema de gestión | ISO/IEC 42001 (AIMS) | ¿Cómo gobierna la organización la IA de forma responsable? | | Operativa | Registro de riesgos de IA y controles | ¿Dónde puede fallar este modelo y qué reduce ese riesgo? | | Aseguramiento | Auditoría de IA (por ejemplo, el alcance AAIA) | ¿Funciona lo anterior según lo previsto? | ## El panorama de las credenciales El título aún se está consolidando. PECB e ISACA son los dos organismos más asociados a la formalización de la competencia en riesgo de IA, y el mercado de certificación es más reciente que el de disciplinas establecidas como el CISA o el ISO 27001 Lead Implementer. En la práctica, a los empleadores les importa menos qué insignia tienes y más si puedes llevar a cabo una evaluación de riesgos de IA defendible, justificar un conjunto de controles y mapear tu trabajo con las cláusulas de ISO 42001 y los niveles de la AI Act. Trata la credencial como evidencia de método, no como el trabajo en sí. > **Nota del profesional** Si ya gestionas el riesgo de seguridad de la información, tienes la mayor parte del camino recorrido. Las competencias transferibles son el registro de riesgos, las decisiones de tratamiento y el reporte a las partes interesadas. El nuevo músculo que hay que desarrollar es comprender el comportamiento del modelo: pruebas de sesgo, monitorización de deriva y explicabilidad, además de la exposición de cadena de suministro que conlleva usar modelos fundacionales que no entrenaste. --- ## Advanced in AI Audit (AAIA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/aaia **Last reviewed:** 2026-06-24 AAIA es la credencial avanzada de ISACA para auditar sistemas, modelos y gobernanza de IA. De reciente creación (desde 2024). Requiere CISA u equivalente previo. Diseñada para auditores senior que incorporan capacidades en IA, mapeada sobre ISO/IEC 42001 y las obligaciones de alto riesgo del AI Act. ## Para qué sirve la credencial AAIA Advanced in AI Audit (AAIA) es una credencial de ISACA pensada para auditores con experiencia que necesitan extender su práctica a la inteligencia artificial. Es una incorporación reciente al portafolio de ISACA, introducida cuando la IA pasó de los proyectos piloto a sistemas en producción que los consejos de administración, los reguladores y los clientes esperan ahora poder asegurar. La premisa es estrecha y deliberada: presupone que usted ya sabe auditar. AAIA no vuelve a enseñar el proceso de auditoría. Le enseña a aplicar la disciplina de auditoría a los sistemas de IA, a los modelos que los sustentan y a la gobernanza que los rodea. Ese enfoque es la razón por la que AAIA se posiciona como avanzada y no de nivel inicial. Se dirige a auditores que ya poseen una credencial de auditoría y un dominio operativo de los controles, la evidencia y los informes, y que ahora deben responder a preguntas que una auditoría de TI tradicional nunca se diseñó para plantear. ¿Son los datos de entrenamiento adecuados para su finalidad? ¿Puede explicarse el comportamiento del modelo? ¿Existe una supervisión humana significativa allí donde el sistema toma decisiones de gran trascendencia? ¿Se utiliza la IA únicamente para su finalidad declarada? Estas son las brechas que AAIA pretende cerrar. ## Prerrequisitos y dónde se sitúa AAIA está diseñada para apoyarse en una base de auditoría existente en lugar de funcionar por sí sola. ISACA la posiciona para auditores sénior, y en la práctica se espera que los candidatos posean CISA o una credencial de auditoría reconocida equivalente antes de abordarla. La lógica es la misma que ISACA aplica en toda su oferta avanzada: la certificación añade una especialización sobre una base probada, no sustituye esa base. Un auditor que nunca ha dirigido un encargo sacará poco provecho de AAIA, mientras que un titular de CISA con experiencia obtiene un método estructurado para hacer defendibles los encargos de IA. > **AAIA presupone que usted ya sabe auditar** Trate AAIA como una especialización superpuesta a una credencial de auditoría existente como CISA, no como una primera certificación. Extiende al auditor que usted ya es hacia los sistemas de IA, los modelos y la gobernanza. ## Cómo se vincula con ISO 42001 y el Reglamento Europeo de IA Lo que hace que AAIA sea práctica y no académica es que se fundamenta en los marcos que ahora se pide a los auditores que verifiquen. Se vincula con ISO/IEC 42001, la norma de sistema de gestión para la IA, que ofrece al auditor una estructura de control reconocida para la gobernanza de la IA: rendición de cuentas, calidad de los datos, transparencia, supervisión humana y evaluación de impacto. También se alinea con las obligaciones que el EU AI Act impone a los sistemas de alto riesgo, donde los proveedores deben operar un sistema de gestión de riesgos, mantener documentación técnica, garantizar la supervisión humana y realizar un seguimiento poscomercialización. AAIA dota al auditor para reunir evidencia precisamente frente a esas expectativas. Aquí es donde AAIA difiere de una cualificación general en gobernanza de IA. Un certificado de gobernanza le enseña a diseñar y operar un sistema de gestión de IA. AAIA le enseña a evaluarlo de forma independiente: planificar una auditoría de IA, acotarla en torno a la finalidad prevista y el riesgo, probar los controles, evaluar la evidencia e informar de hallazgos sobre los que un consejo o un regulador puedan actuar. Es la contraparte de aseguramiento de las competencias de construcción y operación que instalan marcos como ISO 42001. ## Qué hacen realmente los titulares de AAIA En la práctica, un auditor con capacidad AAIA suele recorrer una secuencia reconocible en un encargo de IA: 1. Acotar la auditoría en torno a la finalidad prevista del sistema de IA, su clasificación de riesgo y el papel de la organización como desarrollador, proveedor o implementador. 1. Evaluar la gobernanza: si la rendición de cuentas está asignada, si existen evaluaciones de riesgo e impacto de la IA, y si se mantienen actualizadas. 1. Probar los controles que importan para la IA, incluidos la gobernanza de datos, la documentación de los modelos, la transparencia hacia los usuarios afectados y la supervisión humana. 1. Evaluar el seguimiento posterior al despliegue, la gestión de incidentes y el bucle de retroalimentación que mantiene al sistema dentro de sus límites declarados. 1. Informar de los hallazgos en lenguaje de auditoría que corresponda con claridad a los controles de ISO 42001 y a las obligaciones del AI Act, para que la organización pueda cerrar las brechas con evidencia. El valor para una organización es la independencia. Un equipo de gobernanza de IA puede dar fe de que los controles existen; un auditor dotado con AAIA puede proporcionar el aseguramiento de tipo tercera parte de que esos controles realmente funcionan, que es cada vez más lo que los reguladores, los compradores corporativos y las funciones de compras piden ver. --- ## Agencia Nacional de Ciberseguridad de Francia (ANSSI) **URL:** https://cyberacademy.net/es/resources/encyclopedia/anssi **Last reviewed:** 2026-06-24 ANSSI es la agencia nacional de ciberseguridad de Francia, bajo tutela del Primer Ministro desde 2009. Es la autoridad nacional en materia de política de ciberseguridad en Francia, cualifica productos y proveedores de servicios, publica EBIOS Risk Manager y actúa como autoridad competente para la transposición de NIS 2. Sus cualificaciones (SecNumCloud, PVID, PASSI) son el referente en el sector público francés. ## Que hace la ANSSI La ANSSI (Agence nationale de la securite des systemes d'information) es la autoridad nacional de ciberseguridad de Francia. Depende del Secretariado General de la Defensa y la Seguridad Nacional, bajo la autoridad del Primer Ministro, lo que la mantiene deliberadamente separada de los organismos de inteligencia y de las fuerzas del orden. Esa separacion importa en la practica: la ANSSI es defensiva por diseno, de modo que las organizaciones pueden compartir con ella los detalles de un incidente sin temer que la misma agencia se encargue tambien de operaciones ofensivas o de la persecucion penal. Su ambito es amplio. Define la politica y la doctrina nacionales de ciberseguridad, opera el CERT-FR operativo para la respuesta a incidentes y la inteligencia de amenazas, supervisa a los operadores de importancia vital y a las entidades esenciales, y publica guias y metodos que el resto del ecosistema frances trata como material de referencia. EBIOS Risk Manager, el metodo de analisis de riesgos que muchas organizaciones francesas utilizan para construir los escenarios de amenaza que sustentan su programa de seguridad, lo mantiene la ANSSI y no un organismo privado de normalizacion. ## Cualificaciones y visados La parte de la ANSSI con la que los profesionales tratan de forma mas directa es su esquema de cualificacion. En lugar de limitarse a redactar normas, la ANSSI evalua productos y proveedores de servicios frente a requisitos publicados y concede una cualificacion o un visado de seguridad. Estas etiquetas tienen un peso real porque el sector publico y los operadores regulados suelen exigirlas por politica. - SecNumCloud cualifica a los proveedores de servicios en la nube frente a una exigente base de seguridad y soberania, y se cita cada vez mas como el listón para las cargas de trabajo sensibles del sector publico. - PASSI cualifica a los proveedores de auditoria de seguridad (pruebas de penetracion, revision de configuracion, auditoria de arquitectura) para que un comprador sepa que el auditor fue evaluado frente a un estandar comun. - PVID cubre a los proveedores de verificacion de identidad a distancia, del tipo utilizado en los flujos de incorporacion que deben resistir los deepfakes y el fraude documental. > **Por que importan las etiquetas** Una cualificacion SecNumCloud o PASSI no es una insignia de marketing. Para las administraciones francesas y los operadores de importancia vital es con frecuencia una condicion de contratacion, por lo que perderla o carecer de ella puede excluir a un proveedor de licitaciones enteras. ## La ANSSI frente a la ENISA y el panorama de NIS 2 Es facil confundir a la ANSSI con la ENISA, pero se situan en niveles distintos. La ANSSI es la autoridad nacional de un Estado miembro, Francia. La ENISA es la agencia de la Union Europea que apoya a todos los Estados miembros y gestiona el marco europeo de certificacion de ciberseguridad. Cooperan, pero la ANSSI es el organismo que realmente supervisa a las entidades francesas y puede actuar como autoridad competente cuando las normas europeas se transponen al Derecho frances. NIS 2 es el ejemplo mas claro. La directiva es europea, pero debe transponerse y aplicarse a nivel nacional. En Francia, la ANSSI se posiciona como la autoridad competente que define que entidades estan dentro del ambito, fija las expectativas en materia de gestion de riesgos y notificacion de incidentes, y supervisa el cumplimiento. Asi, cuando una entidad esencial o importante francesa se pregunta a quien debe notificar tras un incidente significativo, la respuesta operativa pasa por la ANSSI y el CERT-FR, y no directamente por Bruselas. Para un profesional de la seguridad o de la GRC, la conclusion practica es tratar a la ANSSI como tres cosas a la vez: una autoridad de politica cuyas orientaciones se siguen, un organismo de cualificacion cuyas etiquetas condicionan las decisiones sobre proveedores y herramientas, y un regulador nacional y socio de respuesta a incidentes con el que se tratara en el marco de NIS 2. --- ## Agencia de la Unión Europea para la Ciberseguridad (ENISA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/enisa **Last reviewed:** 2026-06-24 ENISA es la agencia de ciberseguridad de la UE, con sede en Atenas. Apoya a los estados miembros y a las instituciones europeas en materia de política de ciberseguridad, cooperación operativa y el marco de certificación de la UE. Participa activamente en la cooperación de NIS 2, en las normas de desarrollo de DORA y en la línea de base de seguridad del AI Act. Su informe anual sobre el panorama de amenazas es la publicación anual más citada del sector. ## Qué hace ENISA, y qué no hace ENISA es la Agencia de la Unión Europea para la Ciberseguridad, el organismo de la UE cuya misión es elevar el nivel común de ciberseguridad en toda la Unión. Con sede en Atenas, trabaja junto a los Estados miembros, la Comisión Europea y las instituciones de la UE, apoyando la política, la cooperación operativa y el desarrollo de capacidades, en lugar de ejecutar ella misma la defensa nacional. La distinción importa en la práctica: ENISA no investiga brechas, no impone multas vinculantes ni supervisa empresas individuales. Eso lo hacen las autoridades nacionales competentes y los reguladores sectoriales. ENISA produce las orientaciones, la inteligencia de amenazas y los referentes técnicos en los que se apoyan esas autoridades y las organizaciones reguladas que dependen de ellas. Una forma útil de situar a ENISA es contrastarla con una agencia nacional como la ANSSI francesa. La ANSSI es una autoridad de un Estado miembro con poderes operativos y reguladores dentro de un solo país. ENISA opera un nivel por encima, coordinando a todos los Estados miembros y dando a la UE un punto de referencia técnico único, para que veintisiete enfoques nacionales no se distancien. Cuando ve a un CISO francés citar a ambos, la ANSSI es la autoridad ante la que responde y ENISA es la fuente a escala de la UE con la que se alinea. ## Dónde toca ENISA las regulaciones que usted debe cumplir Para un profesional de GRC, ENISA no es una abstracción. Aparece directamente dentro de los textos respecto a los cuales está usted en el alcance. En el marco de NIS 2, ENISA apoya los mecanismos de cooperación entre Estados miembros, mantiene una conciencia situacional compartida y contribuye a las orientaciones técnicas que ayudan a las entidades esenciales e importantes a interpretar de forma coherente sus obligaciones de seguridad y de notificación de incidentes. En el marco de DORA, ENISA contribuye a las normas técnicas de ejecución y reguladoras que convierten los requisitos de alto nivel del reglamento para las entidades financieras en expectativas concretas. Y a medida que toman forma las disposiciones de seguridad del AI Act, ENISA está posicionada para ayudar a definir el nivel básico de ciberseguridad que se espera de los sistemas de IA de alto riesgo. - NIS 2: cooperación transfronteriza, conciencia situacional y orientación técnica para las entidades esenciales e importantes. - DORA: contribución a las normas técnicas que operativizan la resiliencia operativa digital para las entidades financieras. - EU Cybersecurity Act: ENISA gestiona el marco europeo de certificación de ciberseguridad, desarrollando esquemas que permiten certificar una sola vez los productos, servicios y procesos y que se reconozcan en toda la Unión. > **El marco de certificación es la palanca más concreta de ENISA** El Cybersecurity Act otorgó a ENISA un mandato permanente y le encomendó construir esquemas de certificación a escala de la UE. En lugar de que un proveedor certifique un producto por separado en cada país, un único esquema produce un certificado reconocido en todos los Estados miembros. Esta es la parte del trabajo de ENISA con mayor probabilidad de aparecer en una conversación de contratación o de aseguramiento. ## El resultado que los profesionales realmente leen ENISA publica abundantemente, pero su informe anual Threat Landscape es la obra más citada, el documento de referencia al que recurren los equipos cuando necesitan una visión autorizada, a escala de la UE, sobre cómo evoluciona el panorama de amenazas en los distintos sectores. Los profesionales lo usan para contrastar sus propias evaluaciones de riesgos, para informar a los consejos de administración con una fuente independiente y paneuropea, y para justificar las prioridades de control ante auditores y reguladores. Junto a él, ENISA publica orientaciones sectoriales, guías de buenas prácticas y la base técnica que sustenta los esquemas de certificación. La conclusión práctica es tratar a ENISA como una fuente de autoridad y no como un organismo ante el que se reporta. No se presenta nada ante ENISA. Usted alinea su lenguaje del riesgo, sus referentes de control y sus supuestos de amenaza con lo que ENISA publica, porque esa es la referencia que también leen su autoridad nacional, su auditor y, cada vez más, su regulador. --- ## Apetito de riesgo **URL:** https://cyberacademy.net/es/resources/encyclopedia/risk-appetite **Last reviewed:** 2026-06-24 El apetito de riesgo es la cantidad y el tipo de riesgo que la organización está dispuesta a asumir para alcanzar sus objetivos. Se establece a nivel ejecutivo o de consejo de administración, por escrito. Sin él, cada decisión de tratamiento de riesgos es un juicio personal del equipo de riesgos, y la auditoría lo pondrá en evidencia. Combinar con la tolerancia al riesgo (la desviación admitida respecto al apetito). ## Para qué sirve el apetito de riesgo El apetito de riesgo existe para zanjar una discusión antes de que ocurra. Cada decisión de tratamiento, cada « lo corregimos o convivimos con ello », es en realidad una pregunta sobre cuánto riesgo está dispuesta a asumir la organización frente al beneficio de perseguir sus objetivos. Si esa frontera reside solo en la cabeza de quienes dirigen el programa, entonces cada decisión se convierte en un juicio privado que nadie más firmó, y eso es exactamente lo que un auditor o un cuestionamiento del consejo desmontará. Un apetito escrito, asumido a nivel directivo o del consejo, convierte esos juicios dispersos en una posición organizativa declarada. Es un instrumento de gobierno, no papeleo: indica al equipo de riesgo dónde puede avanzar por su propia autoridad y dónde un riesgo debe escalarse. Algo crucial: el apetito se fija en el lenguaje de los objetivos, no como una cifra única. Una organización que persigue un crecimiento agresivo en un nuevo mercado aceptará racionalmente más riesgo estratégico y operativo que otra cuyo mandato es proteger un servicio regulado y crítico para la vida. El consejo decide cuánta exposición está dispuesto a consentir para lograr lo que pretende. Por eso el apetito no puede delegarse en la función de seguridad o riesgo para que lo invente por su cuenta: es una declaración de intenciones que solo quienes responden de los objetivos pueden formular legítimamente. ## Apetito frente a tolerancia frente a capacidad Estos tres conceptos se confunden constantemente, y la confusión sale cara. El apetito es cuánto riesgo quieres asumir en la persecución de los objetivos. La tolerancia es la desviación que estás dispuesto a aceptar en torno a ese apetito antes de actuar, la banda práctica a ambos lados del objetivo. La capacidad es el máximo absoluto que la organización podría absorber antes de que su viabilidad se vea amenazada, con independencia de lo que quiera. Fijas el apetito por debajo de la capacidad de forma deliberada, dejando margen, y expresas la tolerancia para que la variación cotidiana no provoque una reunión de crisis cada vez. **Apetito, tolerancia y capacidad de un vistazo** | Concepto | Pregunta que responde | Quién es responsable | | --- | --- | --- | | Apetito de riesgo | ¿Cuánto riesgo queremos asumir para cumplir nuestros objetivos? | Consejo / dirección | | Tolerancia al riesgo | ¿Cuánta desviación en torno a ese apetito aceptaremos antes de actuar? | Dirección / propietarios de riesgos | | Capacidad de riesgo | ¿Cuál es el máximo que podríamos absorber antes de que la viabilidad esté en juego? | Consejo (un límite estricto) | > **El apetito sin tolerancia es inviable** Una declaración de apetito desnuda, sin banda de tolerancia, obliga al equipo a tratar cada desviación menor como un incumplimiento. Combina el apetito con una tolerancia declarada para que la fluctuación normal se absorba y solo la deriva genuina se escale. Sin ella, la declaración o se ignora o genera ruido. ## Cómo aparece en las normas En ISO 31000, el apetito de riesgo forma parte del marco que el liderazgo establece cuando se compromete a gestionar el riesgo: se espera que la alta dirección y los órganos de supervisión definan y comuniquen cuánto riesgo está dispuesta a asumir la organización. ISO 27005 y el sistema de gestión de seguridad de la información ISO 27001 se basan en la misma idea a través de los criterios de riesgo: antes de poder evaluar un riesgo, necesitas criterios acordados sobre lo que es aceptable, y esos criterios son el apetito hecho operativo. El apetito está aguas arriba de la evaluación, y los criterios son la manera en que se aplica de forma coherente a cada riesgo. El apetito no es un cartel en la pared. Solo se gana su lugar cuando está integrado en el resto del ciclo. El paso de evaluación del riesgo compara cada riesgo analizado con los criterios derivados del apetito para decidir si es necesaria una acción. La decisión de tratamiento del riesgo, evitar, reducir, transferir o aceptar, se justifica por referencia a él: un riesgo aceptado dentro del apetito solo requiere una aceptación documentada y autorizada, mientras que un riesgo por encima del apetito exige tratamiento o una aprobación formal y escalada. El registro de riesgos consigna dónde se sitúa cada entrada respecto al apetito y quién aceptó qué. Cuando los auditores encuentran decisiones de tratamiento que nadie puede rastrear hasta un apetito declarado, esa es la brecha que desmorona toda la evaluación. En la práctica, el apetito se revisa, no se graba en piedra. Se reexamina a medida que los objetivos cambian, tras incidentes mayores, y a través de la revisión por la dirección, porque un apetito fijado para la estrategia del año pasado desorienta discretamente las decisiones de este año. La disciplina consiste en mantenerlo explícito, mantenerlo asumido en la cúpula y mantenerlo conectado a los criterios que el equipo utiliza realmente. --- ## Auditoría de etapa 1 / etapa 2 **URL:** https://cyberacademy.net/es/resources/encyclopedia/stage-1-2-audit **Last reviewed:** 2026-06-24 La certificación ISO inicial se divide en etapa 1 (revisión de documentación y preparación, normalmente 1-2 días) y etapa 2 (auditoría de evidencias operativas, 2-5 días). La etapa 1 confirma que el sistema de gestión existe sobre el papel; la etapa 2 verifica que funciona en la práctica. La mayoría de las auditorías de etapa 2 «fallidas» son problemas de etapa 1 que nadie corrigió en el intervalo. Una certificación acreditada frente a una norma de sistema de gestión como ISO/IEC 27001 no es una única visita. El organismo de certificación realiza una auditoría inicial en dos fases distintas, que responden a dos preguntas diferentes. La fase 1 pregunta si el sistema de gestión existe y está listo para ser auditado. La fase 2 pregunta si realmente funciona en la práctica. Tratar ambas como un único examen continuo es la forma más habitual en que los equipos se llevan una sorpresa, porque las dos fases recompensan tipos de preparación completamente distintos. ## Qué comprueba realmente la fase 1 La fase 1 es una revisión del estado de preparación y de la documentación, normalmente la más corta de las dos. El auditor lee sus documentos esenciales, confirma que el alcance es coherente y busca los artefactos obligatorios que exige la norma. Para un SGSI eso significa la Declaración de Aplicabilidad, el proceso de evaluación y tratamiento de riesgos, la política de seguridad, los registros de auditoría interna y de revisión por la dirección, y la evidencia de que el sistema lleva funcionando el tiempo suficiente para producir datos. El entregable no es un certificado. Es un resumen escrito de los hallazgos y de las áreas de preocupación que se espera que cierre antes de la fase 2. En la práctica, la fase 1 es su sistema de alerta temprana. El auditor señala las brechas mientras aún hay tiempo para corregirlas. Los equipos que leen esos hallazgos como una lista de tareas llegan preparados a la fase 2. Los equipos que los archivan y siguen adelante son los que después tienen dificultades. ## Qué verifica la fase 2 La fase 2 es la auditoría de la evidencia operativa, y suele ser más larga. El auditor pasa de «la política dice que» a «demuéstreme que ocurrió». Toma muestras de registros, entrevista a las personas que operan los controles, sigue los incidentes y las revisiones de acceso hasta su cierre, y comprueba si el proceso documentado coincide con la realidad diaria. Aquí es donde la Declaración de Aplicabilidad se coteja con evidencia operativa real, y donde los controles débiles que parecían correctos sobre el papel se desmoronan. > **El patrón detrás de la mayoría de las auditorías de fase 2 «fallidas»** Un mal resultado en la fase 2 suele ser un problema de la fase 1 que nadie corrigió en medio. El auditor se lo dijo en la fase 1, tuvo semanas para actuar, y la brecha seguía abierta en la segunda visita. Cierre los hallazgos de la fase 1 de forma deliberada y la fase 2 deparará muchas menos sorpresas. ## Fase 1 frente a fase 2 de un vistazo **Cómo difieren las dos fases en enfoque y resultado** | Dimensión | Fase 1 | Fase 2 | | --- | --- | --- | | Pregunta central | ¿Existe el sistema y está listo? | ¿Opera realmente el sistema? | | Entrada principal | Documentación y revisión del diseño | Registros operativos, entrevistas, muestreo | | Duración típica | Más corta (centrada en la documentación) | Más larga (centrada en la evidencia) | | Salida principal | Hallazgos y áreas de preocupación a cerrar | No conformidades y decisión de certificación | | Qué recompensa | Documentación completa y coherente | Disciplina y evidencia trazable a lo largo del tiempo | ## Qué hacen los profesionales entre las dos visitas La ventana entre la fase 1 y la fase 2 es el verdadero trabajo. Los hallazgos de la fase 1 todavía no son no conformidades, por lo que no hay un plan formal de acciones correctivas, pero son el auditor diciéndole exactamente dónde indagará la fase 2. Los equipos sólidos convierten cada observación de la fase 1 en un responsable, una acción y un plazo, y luego se aseguran de que la evidencia que la cierra resida en los registros que el auditor muestreará. También mantienen el sistema funcionando con normalidad en lugar de organizar una limpieza puntual, porque la fase 2 busca una operación sostenida, no una instantánea ordenada. Cuando la fase 2 sí plantea una no conformidad, la respuesta es la misma disciplina que espera una auditoría de seguimiento: clasificarla con honestidad como mayor o menor, planificar la acción correctiva con un plazo, y abordar la causa raíz en lugar del síntoma. La decisión de certificación llega una vez que el organismo de certificación queda satisfecho de que esas acciones se sostienen. --- ## Autenticación Multifactor (MFA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/mfa **Last reviewed:** 2026-06-24 MFA es el requisito de que la autenticación utilice dos o más factores de categorías distintas (conocimiento, posesión, inherencia). No todo MFA es equivalente: los códigos por SMS y correo electrónico son susceptibles de phishing, las notificaciones push generan fatiga, y los tokens hardware y las passkeys son las formas robustas. NIS 2 y DORA exigen MFA «fuerte» en los accesos críticos. ## Qué cuenta como factor, y por qué importa La autenticación multifactor exige dos o más pruebas de identidad extraídas de categorías diferentes, de modo que comprometer una no entregue la cuenta a un atacante. Las tres categorías clásicas son el conocimiento (algo que sabes, como una contraseña o un PIN), la posesión (algo que tienes, como un teléfono, una llave de seguridad o una tarjeta inteligente) y la inherencia (algo que eres, como una huella dactilar o el rostro). La palabra clave aquí es diferentes. Dos contraseñas no constituyen autenticación multifactor, porque pertenecen a la misma categoría y caen ante los mismos ataques. Una contraseña más un código de un dispositivo independiente sí, porque ahora un atacante necesita vencer dos controles no relacionados a la vez. Aquí es también donde se encuentran la MFA y la gestión de identidades. La MFA solo refuerza el paso de autenticación, el momento en que un usuario demuestra quién es. No dice nada sobre lo que ese usuario tiene luego permitido hacer, lo cual es la autorización, ni sobre el aprovisionamiento, el desaprovisionamiento o las revisiones de acceso. Trate la MFA como una capa endurecida dentro de un programa de IAM más amplio, no como un sustituto del mínimo privilegio ni de la limpieza de cuentas huérfanas. ## No toda MFA es igual La observación más importante del profesional es que la MFA existe en un espectro de robustez, y la diferencia no es cosmética. Los códigos de un solo uso por SMS y correo electrónico son mejores que una contraseña sola, pero son susceptibles de phishing: una página de inicio de sesión falsa y convincente simplemente pide a la víctima que escriba el código, y un atacante lo retransmite en tiempo real. El SIM swapping empeora aún más el SMS. Las aprobaciones por notificación push añaden un toque, pero invitan a la fatiga de MFA, en la que un atacante que ya tiene la contraseña satura de solicitudes de aprobación hasta que un usuario cansado acepta una. Las formas robustas son factores de posesión vinculados al sitio legítimo: llaves de seguridad físicas y passkeys construidas sobre FIDO2 y WebAuthn. Como la credencial está vinculada criptográficamente al dominio real, no entrega nada a una página que imita el original. Esa propiedad es lo que se entiende por MFA resistente al phishing. **Métodos de MFA según su resistencia a los ataques comunes** | Método | Categoría | Resistente al phishing | Debilidad típica | | --- | --- | --- | --- | | Código por SMS o correo electrónico | Posesión (débil) | No | Retransmitido en páginas falsas, SIM swap | | Aplicación de autenticación TOTP | Posesión | No | El código puede ser robado por phishing en tiempo real | | Aprobación por push | Posesión | No | Fatiga de MFA y aprobación accidental | | Llave física (FIDO2) | Posesión | Sí | Coste y logística de inscripción | | Passkey (WebAuthn) | Posesión más inherencia | Sí | Recuperación y vinculación al dispositivo | > **La MFA fuerte es la tarea, no una casilla que marcar** Los reguladores dicen cada vez más fuerte en lugar de simplemente MFA. Desplegar códigos SMS para marcar una casilla de cumplimiento deja la vía del phishing de par en par. Priorice los métodos resistentes al phishing para administradores, acceso remoto y todo aquello que un atacante atacaría primero. ## Contexto normativo y de estándares La MFA ha pasado de ser una recomendación a una expectativa en toda la regulación europea de ciberseguridad. NIS 2 exige a las entidades esenciales e importantes adoptar medidas de ciberhigiene y de control de acceso, mencionando explícitamente la autenticación multifactor o continua para la seguridad del acceso. DORA impone expectativas comparables al sector financiero, donde la autenticación fuerte protege las funciones críticas y el acceso remoto. Ambos marcos se inclinan hacia el extremo fuerte del espectro en lugar de considerar suficiente cualquier MFA. La misma dirección aparece en las directrices del NIST, que favorecen los autenticadores resistentes al phishing para el acceso de alto valor, y en marcos de referencia como ISO/IEC 27001 y los CIS Controls, que tratan la MFA como una salvaguarda fundamental del control de acceso. Lo que los profesionales realmente hacen es secuenciar el despliegue según el riesgo. Protegen primero las cuentas privilegiadas y administrativas, luego el acceso remoto y expuesto a Internet, después la población general de usuarios, y eligen métodos resistentes al phishing allí donde el impacto de una vulneración es alto. Planifican cuidadosamente la recuperación y la inscripción, ya que la pérdida de factores supone un coste operativo real, y vigilan los patrones de fatiga y elusión. Bien hecha, la MFA retira discretamente el valor de una contraseña robada. Hecha como una casilla que marcar, da una falsa sensación de seguridad mientras el canal susceptible de phishing permanece abierto. --- ## Business Email Compromise (BEC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/bec **Last reviewed:** 2026-06-24 BEC es el ataque de ingeniería social dirigido que suplanta a un directivo o proveedor para redirigir un pago o engañar a un empleado para que lo apruebe. No requiere malware; es pretexting puro. La pérdida media por incidente supera con creces a la del ransomware. Los controles de proceso (segregación de funciones, verificación por devolución de llamada) lo detectan; la tecnología por sí sola no. ## Qué diferencia al BEC del phishing común El Business Email Compromise es un fraude ejecutado mediante un pretexto en lugar de una carga maliciosa. El atacante no necesita un enlace malicioso ni un adjunto que instale malware. Necesita una historia plausible, una sensación de urgencia y una víctima con la autoridad para mover dinero o datos. Un dominio suplantado o parecido, un buzón comprometido o una dirección recién registrada que se asemeje a un proveedor conocido bastan para montar el escenario. Como nada técnicamente malicioso cruza la red, las pasarelas de correo seguro, los antivirus y los sandbox de enlaces dejan pasar el mensaje con frecuencia. El ataque vive por completo en la conversación. Por eso el BEC se sitúa junto al phishing en la misma familia y, sin embargo, se comporta de forma diferente en la práctica. El phishing genérico es una red amplia lanzada para conseguir credenciales o clics. El BEC es paciente y selectivo: el atacante investiga el organigrama, averigua quién aprueba las facturas, estudia el tono del correo interno y espera un momento creíble, como una adquisición, una operación inmobiliaria o un director financiero de viaje en el extranjero. La recompensa es una única transferencia fraudulenta o un depósito de nómina redirigido, a menudo por una cantidad elevada, en lugar de una contraseña capturada. ## Las variantes comunes que ven los profesionales El BEC es una categoría, no un único truco. La misma lógica de pretexto se reutiliza contra cualquier proceso que mueva valor dentro de la organización. - Fraude del CEO: un atacante suplanta a un alto directivo y presiona a un empleado de finanzas para que tramite una transferencia urgente y confidencial, apoyándose en la jerarquía y la discreción para desalentar las preguntas. - Fraude de proveedor, también llamado desvío de facturas: un proveedor de confianza parece enviar por correo nuevos datos bancarios, de modo que la siguiente factura legítima se paga en la cuenta del atacante. - Desvío de nóminas: un empleado parece solicitar un cambio de la cuenta de destino de su salario, redirigiendo discretamente su propia paga hacia el defraudador. - Toma de control de cuenta: se compromete un buzón interno real, de modo que la solicitud fraudulenta llega desde una dirección genuina con un historial genuino, lo que elimina la mayoría de las señales de alerta habituales. - Suplantación de abogado o asesor jurídico: el pretexto se apoya en una operación confidencial y con plazo apremiante donde se espera el secreto y verificar parece descortés. ## Por qué aquí el proceso gana a la tecnología La autenticación del correo ayuda. SPF, DKIM y DMARC elevan el coste de la suplantación directa de dominio y deben implantarse. Pero no hacen nada contra un dominio parecido, una dirección de correo web gratuita o un buzón interno realmente comprometido, que son los canales que más usa el BEC real. Los controles decisivos son procedimentales, en manos de finanzas y operaciones más que de las herramientas de seguridad. - Segregación de funciones para que ninguna persona pueda solicitar y liberar un pago al mismo tiempo. - Verificación por devolución de llamada fuera de banda: confirme cualquier dato bancario nuevo o modificado, y cualquier transferencia inusual, usando un número de teléfono que ya conste en el registro, nunca un número o contacto facilitado dentro de la propia solicitud. - Una regla estricta de que la urgencia y la confidencialidad nunca eluden el circuito de aprobación estándar; esas dos emociones son las herramientas del atacante. - Umbrales de doble autorización para las transferencias y los cambios de datos bancarios de proveedores. > **Verificar la solicitud, no el buzón** El BEC más peligroso llega desde una dirección real y de confianza porque el buzón fue tomado. Un remitente impecable, una firma válida y un bloque de firma familiar no prueban nada. Verifique la propia instrucción a través de un canal independiente antes de que se mueva el dinero. ## Dónde encaja el BEC en el panorama regulatorio El BEC es una causa principal de pérdidas financieras ligadas al correo, lo que lo sitúa de lleno dentro del alcance que un sistema de gestión de la seguridad de la información está destinado a abordar. Bajo un SGSI ISO 27001, el tratamiento pertinente combina formación de concienciación, controles de relaciones con proveedores y los procedimientos operativos que rigen los pagos. Cuando el BEC tiene éxito y se exponen datos personales, por ejemplo a través de un buzón comprometido lleno de correspondencia, también puede activar obligaciones de violación de datos personales bajo el GDPR, razón por la cual el plan de respuesta debe involucrar al área jurídica y a la función de protección de datos, no solo a finanzas y a TI. Para los profesionales, la conclusión es que la defensa contra el BEC es una responsabilidad compartida. Seguridad posee la autenticación del correo, la supervisión y la concienciación. Finanzas posee los controles de pago que realmente detienen el fraude. Tratarlo como un problema puramente técnico que se resuelve con una mejor pasarela es el error que mantiene el flujo de las pérdidas. --- ## Business Impact Analysis (BIA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/bia **Last reviewed:** 2026-06-24 Un BIA es el análisis estructurado que cuantifica el impacto de una interrupción sobre cada actividad crítica a lo largo del tiempo. Los resultados incluyen el objetivo de tiempo de recuperación, el objetivo de punto de recuperación y el objetivo mínimo de continuidad de negocio. Es un input obligatorio para ISO 22301 y DORA. Bien ejecutado, se convierte en el documento que el consejo de administración realmente lee. ## Lo que realmente hace una BIA Un Business Impact Analysis responde a una pregunta de la que depende el resto del programa de continuidad: si esta actividad se detiene, ¿qué tan grave llega a ser, y con qué rapidez? Toma cada actividad de negocio, la proyecta en el tiempo y describe las consecuencias de su interrupción en cada intervalo. Algunas actividades duelen en cuestión de minutos, el procesamiento de pagos o el mostrador de admisiones de un hospital. Otras pueden estar caídas durante días antes de que alguien fuera del equipo se dé cuenta. La BIA es lo que separa ambas, de modo que los escasos recursos de recuperación vayan donde el daño se acumula más rápido y no donde se sienta el directivo que más alza la voz. El impacto se evalúa a través de varias dimensiones, no solo la pérdida de ingresos. La pérdida financiera es la más obvia, pero una BIA seria también captura la exposición regulatoria y legal, las penalizaciones contractuales, la seguridad de las personas y el daño reputacional. Una consecuencia trivial en euros puede ser existencial en términos de confianza. El sentido de mirar a través de las dimensiones es que la actividad que encabeza la lista en dinero rara vez es la misma que encabeza la lista en lo legal o lo de seguridad, y el consejo necesita verlas todas antes de fijar prioridades. ## Del impacto a los objetivos La BIA no se detiene en la descripción. Produce las cifras sobre las que se construye la estrategia de recuperación. A medida que el impacto aumenta con el tiempo, se alcanza el punto en que se vuelve inaceptable. Ese umbral fija el recovery time objective, el periodo máximo tolerable que la actividad puede permanecer caída. El recovery point objective surge del mismo ejercicio en el lado de los datos: cuánto trabajo reciente, medido en tiempo, puede perderse antes de que la interrupción cause un daño inaceptable. El minimum business continuity objective describe el nivel de operación reducido que debe sostener durante la interrupción, no el servicio completo, pero sí lo suficiente para seguir siendo viable. Estos resultados son la entrada formal de la estrategia de continuidad. Un recovery time objective es un requisito impuesto a la solución de recuperación, no un deseo. Si la BIA dice que una actividad debe estar restablecida dentro de una ventana ajustada, la estrategia y el presupuesto tienen que cumplirlo, o la organización tiene que aceptar conscientemente la brecha. Por eso la BIA es el documento que deberían firmar los responsables de negocio y leer el consejo, en lugar de redactarlo el área de IT de forma aislada. > **Las cifras pertenecen al negocio** El fallo más común es una BIA en la que los objetivos de recuperación fueron fijados por personal técnico sin los responsables de la actividad en la sala. Esas cifras parecen precisas sobre el papel y se desmoronan ante un incidente real, porque nadie que cargue con la consecuencia las acordó jamás. Valide cada RTO y RPO con las personas responsables de la actividad. ## Dónde se sitúa la BIA en las normas Bajo ISO 22301, la BIA es un paso obligatorio para establecer un sistema de gestión de la continuidad de negocio. La norma espera que determine las actividades que respaldan la entrega de productos y servicios, evalúe los impactos a lo largo del tiempo de no ejecutarlas y lo use para fijar plazos priorizados de reanudación. La BIA alimenta directamente la evaluación de riesgos y la elección de la estrategia de continuidad. Bajo DORA, la misma lógica se aplica a la resiliencia operativa digital: se espera que las entidades financieras comprendan el impacto de una interrupción sobre sus funciones críticas o importantes, y esa comprensión empieza por un análisis de impacto. Una BIA no es una evaluación de riesgos, y confundir ambas debilita a las dos. La evaluación de riesgos pregunta qué podría causar una interrupción y qué tan probable es. La BIA es deliberadamente agnóstica respecto a las amenazas: pregunta cuánto duele una interrupción con independencia de la causa, ya sea el desencadenante un ciberataque, una inundación o un proveedor que falla. Se ejecutan como ejercicios complementarios. La BIA le dice qué debe protegerse y con qué rapidez debe recuperarse; la evaluación de riesgos le dice qué es lo más probable que lo amenace. Juntas justifican adónde va la inversión en continuidad. En la práctica, una BIA se repite según un ciclo y tras un cambio importante, porque las actividades, las dependencias y las tolerancias se desvían. El proveedor que el año pasado era periférico está ahora en su ruta crítica; el proceso que podía perder durante dos días está ahora de cara al cliente. Una BIA con dos reestructuraciones de antigüedad es decoración. --- ## CIS Controls **URL:** https://cyberacademy.net/es/resources/encyclopedia/cis-controls **Last reviewed:** 2026-06-24 Los CIS Critical Security Controls son un conjunto priorizado de 18 categorías de controles publicado por el Center for Internet Security. Los grupos de implementación (IG1, IG2, IG3) se adaptan a la madurez de la organización. La vía más rápida para llevar a una organización pequeña o mediana desde cero hasta un nivel de defensa sostenible. Se alinea con precisión con el Anexo A de ISO/IEC 27001. ## Qué son realmente los CIS Controls Los CIS Critical Security Controls son una respuesta ordenada y con criterio a una pregunta que enfrenta todo defensor: de todo lo que podrías hacer, ¿qué deberías hacer primero? Publicados y mantenidos por el Center for Internet Security, destilan datos de ataques reales en un conjunto priorizado de salvaguardas agrupadas en 18 categorías de controles, desde el inventario de activos y software de la empresa hasta la protección de datos, el control de accesos, la gestión continua de vulnerabilidades, la gestión de registros de auditoría y la respuesta a incidentes. A diferencia de un marco que te dice que establezcas un proceso, los Controls te dicen concretamente qué implementar y, a grandes rasgos, en qué orden, razón por la cual suelen ser la vía más rápida para pasar de no tener programa de seguridad a tener uno defendible. El rasgo definitorio es la priorización. La lista no es alfabética ni teórica; los controles iniciales son los que bloquean los ataques más comunes. Saber qué hardware y software tienes, configurarlo de forma segura, controlar los privilegios administrativos y parchear las vulnerabilidades conocidas previene una gran parte de los incidentes reales antes de que gastes un solo euro en herramientas avanzadas. Ese orden es el valor: un equipo pequeño con tiempo limitado puede empezar por arriba e ir bajando, con la confianza de estar cerrando las brechas que los atacantes realmente explotan. ## Los Implementation Groups: IG1, IG2, IG3 Los Controls escalan a través de tres Implementation Groups, de modo que el mismo catálogo sirva tanto a un negocio de dos personas como a una multinacional. IG1 se define como higiene cibernética básica, el conjunto mínimo que toda organización debería tener implementado, diseñado para empresas con conocimientos y recursos limitados para protegerse frente a ataques no sofisticados y oportunistas. IG2 añade salvaguardas para organizaciones que gestionan datos más sensibles y se enfrentan a adversarios más capaces. IG3 es el conjunto completo, destinado a organizaciones maduras que poseen activos críticos y deben defenderse de ataques dirigidos y sofisticados. Cada grupo es acumulativo: IG2 incluye todo lo de IG1, e IG3 incluye todo lo de IG1 e IG2. **CIS Implementation Groups** | Grupo | A quién se ajusta | Postura | | --- | --- | --- | | IG1 | Organizaciones pequeñas y medianas, recursos de TI y seguridad limitados | Higiene cibernética esencial, defensa de base | | IG2 | Organizaciones que manejan datos más sensibles, personal de seguridad dedicado | Reforzada frente a atacantes más capaces | | IG3 | Organizaciones maduras con activos críticos y alta exposición | Conjunto completo de salvaguardas frente a ataques dirigidos | En la práctica, te autoevalúas para situarte en un Implementation Group y luego tratas las salvaguardas de ese grupo como tu plan de trabajo. La mayoría de las organizaciones pequeñas y medianas deberían apuntar de lleno primero a IG1 y solo pasar a IG2 una vez que este esté consolidado. Esto es lo que hace que los Controls sean accesibles allí donde un sistema de gestión completo puede parecer fuera de alcance: se te entrega una lista de comprobación finita, comprobable y dimensionada a tu realidad. ## Dónde se sitúan junto a la ISO 27001 y otros marcos Los CIS Controls son un catálogo de controles, no un sistema de gestión certificable, y esa distinción importa. La ISO 27001 certifica que operas un sistema de gestión de la seguridad de la información con evaluación de riesgos, una Declaración de Aplicabilidad y mejora continua; el CIS te ofrece un conjunto concreto y priorizado de salvaguardas técnicas y operativas para implementar por debajo. Son complementarios, no competidores. El CIS publica correspondencias entre sus salvaguardas y el Anexo A de la ISO 27001 y otras referencias como los marcos NIST, de modo que el trabajo de implementación que realizas para el CIS se convierte en evidencia que puedes presentar frente a un conjunto de controles ISO. Los equipos usan con frecuencia el CIS para impulsar el endurecimiento práctico y luego mapear ese esfuerzo hacia el marco que exijan sus auditores o clientes. > **Empieza por arriba, no por todas partes** Los Controls están ordenados por una razón. Un equipo pequeño obtiene más protección al completar IG1 en orden, empezando por el inventario de activos y software y la configuración segura, que al elegir a la carta salvaguardas avanzadas mientras los fundamentos siguen abiertos. --- ## COBIT **URL:** https://cyberacademy.net/es/resources/encyclopedia/cobit **Last reviewed:** 2026-06-24 COBIT es el marco de ISACA para el gobierno y la gestión de las TI empresariales. La edición actual es COBIT 2019. Es el marco que utilizan las Big Four para evaluar la madurez del gobierno de TI y la referencia para la credencial CGEIT. Más estratégico que ISO 27001; menos prescriptivo que NIST. ## Lo que COBIT realmente gobierna COBIT es el marco de ISACA para el gobierno y la gestión de las TI de la empresa. Su distinción fundamental, y aquella en la que más tropiezan los profesionales, es la línea que traza entre gobierno y gestión. El gobierno corresponde al consejo de administración y a la alta dirección: fijar el rumbo, evaluar opciones y supervisar los resultados. La gestión consiste en planificar, construir, operar y supervisar las actividades que materializan ese rumbo. COBIT mantiene ambas dimensiones como dominios separados, de modo que quienes deciden qué deben lograr las TI no sean las mismas personas que informan sobre si se logró. Esa separación es la razón por la que los auditores recurren a COBIT cuando una norma de seguridad de la información no es suficiente. ISO 27001 le indica cómo operar un sistema de gestión de la seguridad de la información. NIST le ofrece un catálogo de controles y resultados. COBIT se sitúa por encima de ambos: responde a si las TI en su conjunto están orientadas hacia los objetivos de la empresa, si el riesgo y los recursos se gestionan de forma responsable, y si las partes interesadas obtienen valor. Es más amplio que la seguridad y deliberadamente menos prescriptivo que una lista de controles. ## La estructura de COBIT 2019 La edición actual es COBIT 2019. Organiza el trabajo en objetivos agrupados bajo dominios de gobierno y gestión, y asocia a cada uno los componentes necesarios para que funcione: procesos, estructuras organizativas, políticas, flujos de información, cultura, competencias y servicios. La idea es que un proceso sobre el papel no significa nada si faltan las estructuras, las competencias y la cultura que lo rodean, por lo que COBIT le obliga a examinarlos todos en conjunto. Dos ideas hacen que COBIT 2019 sea utilizable en la práctica y no solo un cartel en la pared: - Los factores de diseño. La estrategia de la empresa, el perfil de riesgo, los requisitos de cumplimiento, el papel de las TI y el modelo de aprovisionamiento determinan en conjunto qué objetivos merecen atención. COBIT no supone que cada organización necesite el mismo sistema de gobierno, de modo que usted adapta el marco al contexto en lugar de adoptarlo en bloque. - La capacidad y la madurez. Cada objetivo de gobierno y gestión puede valorarse en una escala de capacidad, y el marco también admite una visión de la madurez por áreas de enfoque. Así es como las Big Four y los equipos de auditoría interna producen una imagen defendible del «dónde estamos, dónde deberíamos estar» en lugar de una opinión subjetiva. > **COBIT es una lente, no una lista de verificación** Uno no «implementa COBIT» de la forma en que implementa un SGSI. Lo utiliza para evaluar lo bien que se gobiernan las TI, para diseñar un sistema de gobierno adecuado a su contexto, y para mapear y racionalizar las normas que ya tiene en marcha, como ISO 27001, NIST o ITIL, en un todo coherente. ## Dónde encaja COBIT junto a otros marcos Los profesionales casi siempre utilizan COBIT junto a otros marcos en lugar de en su lugar. Un patrón habitual: COBIT define los objetivos de gobierno y la línea base de madurez, ISO 27001 operativiza la seguridad de la información, ITIL gestiona los servicios, y un marco de riesgo alimenta la imagen del riesgo. COBIT se convierte en el paraguas que muestra cómo estas piezas sirven a los objetivos de la empresa y dónde están las brechas. **COBIT comparado con marcos vecinos** | Marco | Enfoque principal | Posicionamiento | | --- | --- | --- | | COBIT | Gobierno y gestión de las TI de la empresa | Estratégico, a nivel de marco, adaptado al contexto | | ISO 27001 | Sistema de gestión de la seguridad de la información | Certificable, operativo, alcance de seguridad | | Marcos NIST | Resultados de ciberseguridad y catálogos de controles | Detallado, prescriptivo, orientado a controles | | ITIL | Gestión de servicios de TI | Operativo, centrado en la entrega de servicios | COBIT es también el cuerpo de conocimiento que sustenta la credencial CGEIT de ISACA, dirigida a los profesionales responsables del gobierno de las TI de la empresa. Si su función es asegurar o diseñar cómo se dirigen las TI a nivel del consejo, COBIT es el marco de referencia y CGEIT la certificación correspondiente. --- ## Certificación de Profesional en Ciberseguridad (CSX-P) **URL:** https://cyberacademy.net/es/resources/encyclopedia/csx-p **Last reviewed:** 2026-06-24 CSX-P es la credencial de profesional en ciberseguridad de ISACA basada en desempeño. Se evalúa en un entorno de cyber-range en vivo sobre las cinco funciones del NIST CSF. Menos conocida que CISM o CISA, pero es de las pocas credenciales donde el examen pone a prueba lo que realmente se hace, no lo que se sabe escribir. El CSX-P (Cybersecurity Practitioner) es la respuesta de ISACA a una crítica recurrente hacia las certificaciones de seguridad: que la mayoría comprueba si sabes reconocer la respuesta correcta en una pregunta de opción múltiple, no si sabes hacer el trabajo. El CSX-P se realiza en un entorno cyber-range en vivo, donde se sumerge al candidato en escenarios realistas y debe operar herramientas reales frente a condiciones reales. Está construido en torno a las funciones del NIST Cybersecurity Framework, de modo que el examen sigue el ciclo de vida que vive un defensor en lugar de una lista de definiciones memorizadas. ## Lo que distingue al CSX-P: un examen de desempeño La mayoría de las credenciales conocidas, incluidas las propias CISM y CISA de ISACA, son exámenes de conocimiento y criterio. Respondes preguntas; la certificación acredita que comprendes los conceptos y sabes razonar sobre ellos. El CSX-P invierte eso. En lugar de preguntarte qué harías, te coloca en un entorno y observa lo que realmente haces. El candidato resuelve tareas a través de las funciones del NIST CSF, usando sistemas y herramientas de seguridad reales, bajo condiciones diseñadas para asemejarse al trabajo. Por eso la shortDefinition lo plantea como la rara credencial que evalúa lo que haces en lugar de lo que sabes escribir al respecto. - Identify: comprender el entorno, sus activos y dónde reside la exposición. - Protect: aplicar y configurar controles para reducir esa exposición. - Detect: detectar actividad anómala o maliciosa en la telemetría en lugar de esperar a que sea reportada. - Respond: contener un incidente y actuar una vez que se reconoce. - Recover: restaurar sistemas y servicios a un estado correcto conocido después del evento. > **Basado en el desempeño, por diseño** El CSX-P es un examen práctico y guiado por escenarios en un laboratorio virtual. El objetivo es evidenciar capacidad operativa en condiciones realistas. Eso lo acerca, en espíritu, a una evaluación práctica de laboratorio más que a una certificación escrita tradicional. ## El CSX-P junto al CISM y al CISA El CSX-P es menos conocido que el CISM o el CISA, y esa diferencia refleja el público al que se dirige más que el rigor. El CISM es para quien gobierna un programa de seguridad, y el CISA para quien proporciona aseguramiento independiente sobre los controles. Ambos validan criterio y capacidad de gestión o auditoría. El CSX-P valida la ejecución técnica: ¿puedes realmente defender un entorno a lo largo de todo el ciclo de vida del NIST CSF. Son señales complementarias, no rivales, y un equipo sólido puede tener las tres entre personas distintas. **Examen de conocimiento vs examen de desempeño** | Credencial | Centro de gravedad | Cómo se evalúa | | --- | --- | --- | | CSX-P | Práctica operativa de ciberseguridad | Cyber-range en vivo, basado en el desempeño | | CISM | Gobernanza de un programa de seguridad | Conocimiento y criterio, escrito | | CISA | Auditoría y aseguramiento de SI | Conocimiento y criterio, escrito | Como el CSX-P demuestra el hacer en lugar del saber, encaja mal con alguien que apunta de lleno a la auditoría o la gobernanza, y encaja muy bien con alguien que quiere que se reconozca su capacidad operativa de defensa. La decisión gira en torno al rol, no a la antigüedad: un profesional que trabaja con las manos en la masa se beneficia de una credencial que refleja su trabajo, mientras que a un gerente o auditor suele convenirle más el CISM o el CISA. ## A quién le conviene El CSX-P tiene más sentido para profesionales técnicos: analistas, defensores e ingenieros que ya realizan, o quieren orientarse hacia, operaciones de seguridad prácticas a través de las funciones del NIST CSF. Por estar anclado a ese marco, conviene a quienes trabajan en entornos que ya usan el CSF como referencia, incluidas las organizaciones transatlánticas que lo combinan con ISO 27001. Como con cualquier certificación, un empleador valora en última instancia la capacidad demostrada. El valor del CSX-P es precisamente que ofrece una forma estructurada e independiente de proveedores para probar las habilidades prácticas que su nombre indica, en lugar de pedir a un empleador que dé por sentada la competencia. --- ## Certificate of Cloud Auditing Knowledge (CCAK) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ccak **Last reviewed:** 2026-06-24 CCAK es la credencial conjunta de ISACA y Cloud Security Alliance para auditores de nube. Abarca la gobernanza cloud, el CCM, el programa STAR y las consideraciones de auditoría específicas de los hyperscalers. La extensión natural para un titular de CISA cuyo alcance ha pasado a ser cloud-first. ## Qué certifica realmente el CCAK El Certificate of Cloud Auditing Knowledge es una credencial conjunta de ISACA y la Cloud Security Alliance, y responde a una carencia concreta. La formación tradicional en auditoría de TI presupone que puedes recorrer el centro de datos, inspeccionar los tickets de cambios y probar de extremo a extremo controles que la organización posee íntegramente. En la nube, esa premisa se rompe. El proveedor opera la infraestructura física, el hipervisor y grandes partes de la plataforma, y tú nunca los ves. El CCAK está construido en torno a cómo auditar y dar aseguramiento a ese esquema: cómo se reparte la responsabilidad de los controles entre cliente y proveedor, qué evidencia puedes obtener realmente, y cómo razonar sobre el aseguramiento cuando no puedes realizar la prueba tú mismo. Es un certificado de conocimientos más que una certificación condicionada por la experiencia, por lo que no lleva asociado un requisito de experiencia de varios años como sí ocurre con el CISA. Eso lo hace accesible más temprano en una carrera, pero se posiciona como complemento de credenciales de auditoría más profundas y no como sustituto. El lector natural es alguien que ya domina el método de auditoría y ahora necesita encima la capa específica de la nube. ## Qué abarca el cuerpo de conocimientos El CCAK está anclado en las propias herramientas de la CSA y no en la documentación de un único proveedor, que es lo que lo mantiene neutral respecto al fabricante. Los principales puntos de referencia con los que los profesionales aprenden a trabajar incluyen: - La Cloud Controls Matrix (CCM), el marco de controles de la CSA mapeado a través de los dominios de la nube y correlacionado con normas como ISO 27001 y los principales regímenes regulatorios. Es el catálogo de controles frente al cual evalúas un entorno de nube. - El Consensus Assessments Initiative Questionnaire (CAIQ), el conjunto normalizado de preguntas que un cliente plantea a un proveedor para entender qué controles de la CCM opera el proveedor y cómo. - El programa STAR (Security, Trust, Assurance and Risk), el registro de aseguramiento de la CSA. STAR tiene niveles que van desde la autoevaluación del proveedor hasta la certificación por un tercero, y el CCAK te enseña a leer qué demuestra y qué no demuestra cada nivel. - La responsabilidad compartida, la asignación de controles y las consideraciones de auditoría propias de cada proveedor a través de los principales hyperscalers, de modo que sepas qué controles pruebas tú, cuáles atestigua el proveedor y dónde está la junta entre ambos. > **Un certificado de conocimientos, no una certificación de SGSI** El CCAK certifica el conocimiento de una persona en auditoría de la nube. Se distingue de CSA STAR, que es la vía por la cual un servicio en la nube obtiene aseguramiento. Aprendes a evaluar STAR; STAR no se te otorga a ti. ## Dónde se sitúa el CCAK respecto al CISA y al CCSP Los profesionales confunden con frecuencia el CCAK con las dos credenciales entre las que se ubica, así que vale la pena trazar la distinción con claridad. El CISA establece que eres capaz de auditar sistemas de información, sin más. El CCSP, de (ISC)2, es una credencial amplia de diseño y arquitectura de seguridad de la nube. El CCAK es más estrecho y más específico que cualquiera de los dos: trata sobre dar aseguramiento a la nube, no sobre construirla ni sobre auditar sistemas en general. **El CCAK comparado con credenciales vecinas** | Credencial | Enfoque principal | Postura | | --- | --- | --- | | CCAK | Auditoría y aseguramiento de entornos de nube | Específico de la nube, basado en conocimientos, neutral respecto al fabricante | | CISA | Auditoría de sistemas de información en general | Método de auditoría amplio, condicionado por la experiencia | | CCSP | Diseño y protección de la arquitectura de la nube | Arquitectura de seguridad, no centrada en la auditoría | En la práctica, el emparejamiento más sólido es CISA más CCAK. El CISA aporta la disciplina de auditoría, los estándares de evidencia y la mentalidad de independencia; el CCAK añade la capa de nube, de modo que un titular del CISA cuyo alcance ha pasado a ser cloud-first pueda evaluar las fronteras de la responsabilidad compartida y leer evidencia STAR sin reaprender auditoría desde cero. Esa es la progresión que el CCAK está diseñado para servir. --- ## Certified Cybersecurity Operations Analyst (CCOA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ccoa **Last reviewed:** 2026-06-24 CCOA es la credencial de operaciones de ciberseguridad práctica de ISACA, orientada al trabajo en SOC: monitorización, detección, respuesta y recuperación. El complemento técnico del CISM. Más adecuada para analistas y gestores de incidentes que para directivos o auditores. El Certified Cybersecurity Operations Analyst (CCOA) es la credencial de ISACA dirigida a las personas que trabajan en el centro de operaciones de seguridad y realizan el trabajo técnico, no a quienes redactan la política por encima de ellas. Está construida en torno a la realidad diaria de un SOC: vigilar la telemetría, separar las señales reales del ruido, investigar alertas, contener incidentes y devolver los sistemas a un estado correcto conocido. Allí donde la mayoría de las certificaciones de ISACA validan la gobernanza, la auditoría o el criterio de gestión, el CCOA valida si realmente sabes operar las herramientas y responder a lo que estas revelan. ## Qué valida el CCOA El CCOA se organiza en torno al ciclo de vida operativo que vive un defensor durante una semana normal. Las competencias que certifica se corresponden con el trabajo de supervisar un entorno, reconocer cuándo algo va mal, actuar en consecuencia y restaurar el servicio. En la práctica, esto significa competencia en unas pocas áreas conectadas. - Supervisión y detección: trabajar con registros, telemetría de red y de endpoint, y herramientas de detección para detectar actividad anómala o maliciosa en lugar de esperar a que sea notificada. - Triaje e investigación: decidir qué alertas son reales, delimitar el radio de impacto y reconstruir lo sucedido a partir de las evidencias disponibles. - Respuesta a incidentes: contener, erradicar y recuperarse de los incidentes, y después documentar lo aprendido para que la misma brecha no vuelva a abrirse. - Soltura técnica subyacente: redes, sistemas operativos, técnicas de ataque comunes y los controles de seguridad que se interponen entre un atacante y el activo. > **Una credencial práctica, por diseño** El CCOA se posiciona como una certificación práctica, orientada al rendimiento. El objetivo es demostrar que sabes hacer el trabajo en un entorno real, no solo describir su teoría. Eso le confiere un carácter distinto del estilo basado en el conocimiento y el criterio de las certificaciones de gestión y auditoría de ISACA. ## El CCOA junto al CISM y al resto del conjunto ISACA La forma más clara de situar el CCOA es pensar en quién es dueño de qué pregunta. El CISM, la credencial insignia de gestión de ISACA, es para la persona responsable del programa de seguridad: estrategia, gobernanza, riesgo y el marco de gestión de incidentes. El CCOA es para la persona que ejecuta dentro de ese marco cuando salta una alerta a las 2 de la madrugada. Son complementarios, no competidores. Un equipo puede, con buen criterio, contar con un gestor titular del CISM que marca la dirección y analistas titulares del CCOA que realizan la defensa operativa por debajo. Por eso precisamente la shortDefinition califica al CCOA como el complemento técnico del CISM. **Dónde se sitúa el CCOA entre las credenciales de ISACA** | Credencial | Público principal | Centro de gravedad | | --- | --- | --- | | CCOA | Analistas de SOC, respondedores a incidentes | Detección, respuesta y recuperación prácticas | | CISM | Gestores y responsables de seguridad | Gobernanza, estrategia y riesgo del programa | | CISA | Auditores de SI | Aseguramiento independiente y prueba de controles | | CRISC | Profesionales de riesgo y controles | Gestión del riesgo de TI empresarial | Como el CCOA se centra en la ejecución, encaja mal con alguien que quiere pasar a la auditoría o la gobernanza y encaja muy bien con alguien que quiere que se reconozca su capacidad operativa. Los analistas y respondedores obtienen una señal neutral respecto al proveedor de que saben defender un entorno; los gestores y auditores suelen quedar mejor servidos por el CISM, el CISA o el CRISC. Aborda la elección como una cuestión de rol, no de antigüedad. ## A quién va dirigido El CCOA tiene más sentido para profesionales que ya trabajan en un rol operativo de blue team o avanzan hacia él: analistas de SOC de nivel uno y dos, respondedores a incidentes junior e ingenieros de detección que quieren una credencial reconocida que refleje lo que realmente hacen. También es un paso siguiente coherente para personas que empezaron en el lado técnico y quieren una insignia respaldada por ISACA sin dar el salto a la gestión. Como con cualquier certificación, los empleadores valoran en última instancia la capacidad demostrada, así que el valor del CCOA reside en que ofrece una forma estructurada y neutral respecto al proveedor de demostrar las competencias operativas que su título nombra. --- ## Certified Data Privacy Solutions Engineer (CDPSE) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cdpse **Last reviewed:** 2026-06-24 CDPSE es la certificación técnica de privacidad de ISACA. Tres dominios: gobernanza de privacidad, arquitectura de privacidad y ciclo de vida del dato. Complemento técnico de las certificaciones DPO/CDPO orientadas a política. Muy adecuada para equipos de seguridad responsables de la implementación de privacidad y para arquitectos que trabajan bajo el GDPR o el AI Act. ## Para qué sirve CDPSE CDPSE es la respuesta de ISACA a una brecha que se abrió cuando la privacidad dejó de ser un ejercicio puramente jurídico. Redactar una política de privacidad, cartografiar las bases jurídicas y responder a las solicitudes de los interesados es el trabajo de un delegado de protección de datos. Pero nada de eso impide que una API con fugas exponga datos personales, garantiza que la seudonimización se aplique correctamente ni incorpora la lógica de consentimiento y conservación en un sistema antes de su puesta en producción. CDPSE certifica a las personas que realizan ese trabajo técnico: los ingenieros, arquitectos y profesionales de la seguridad que traducen las obligaciones de privacidad en sistemas y controles operativos. Esa es la postura que define esta credencial. Es la compañera del lado de la ingeniería de las credenciales DPO y CDPO, centradas en la política, no una competidora de ellas. Un DPO decide qué debe hacer la organización para cumplir; un titular de CDPSE construye los controles que hacen el cumplimiento real y verificable. En los programas maduros, ambos roles se sientan a uno y otro lado de la misma mesa, por lo que CDPSE se posiciona como un puente entre la gobernanza de la privacidad y la tecnología que la implementa. ## Los tres dominios CDPSE se estructura en torno a tres dominios, y sus proporciones le indican dónde pone ISACA el énfasis. La mayor parte del examen recae en los dominios de arquitectura y ciclo de vida, porque ahí es donde realmente se toman las decisiones de ingeniería. - Gobernanza de la privacidad. El tejido conectivo entre los requisitos jurídicos y la ejecución técnica: estructura del programa de privacidad, gobernanza y gestión del riesgo de privacidad, y las políticas y normas sobre las que la ingeniería debe construir. Aquí es donde un titular de CDPSE lee lo que el DPO y el equipo jurídico produjeron y lo convierte en restricciones de diseño. - Arquitectura de la privacidad. Infraestructura, aplicaciones y tecnologías desde la óptica de la privacidad. Abarca la privacidad desde el diseño y por defecto como disciplina de ingeniería: diseño de flujos de datos, controles técnicos de privacidad, cifrado y seudonimización, identidad y acceso, y las implicaciones para la privacidad de las decisiones arquitectónicas. - Ciclo de vida de los datos. Los datos personales desde la recogida hasta la destrucción, pasando por la conservación. Limitación de la finalidad, minimización de datos, calidad, calendarios de conservación y eliminación segura, expresados como controles que un sistema aplica en lugar de cláusulas en un aviso que nadie lee. > **Implementación, no interpretación** CDPSE da por supuesto que la interpretación jurídica ya existe. Su valor reside en hacer operativa esa interpretación: consentimiento recogido correctamente, conservación aplicada automáticamente, acceso limitado a la finalidad, datos suprimibles a petición. Si su trabajo consiste en discutir el significado de una norma, eso es terreno del DPO; si su trabajo consiste en hacer que el sistema la obedezca, eso es terreno de CDPSE. ## El lugar de CDPSE junto a credenciales y normas vecinas CDPSE resulta más útil cuando se lee frente a lo que no es. La tabla siguiente la sitúa junto a las credenciales y normas con las que los profesionales más a menudo la confunden. **CDPSE comparada con roles y normas de privacidad vecinos** | Referencia | Enfoque principal | Postura | | --- | --- | --- | | CDPSE | Implementación técnica de la privacidad en los sistemas | Ingeniería y arquitectura, controles operativos | | DPO / CDPO | Cumplimiento jurídico y de políticas, rendición de cuentas | Gobernanza, interpretación, asesoramiento | | ISO 27701 | Sistema de gestión de la información de privacidad (PIMS) | Sistema de gestión certificable que extiende ISO 27001 | | GDPR | Las propias obligaciones jurídicas | Regulación, aquello que los controles deben satisfacer | La idoneidad es mayor para los equipos de seguridad que han heredado la implementación de la privacidad, y para los arquitectos que diseñan bajo el GDPR o el AI Act, donde la minimización de datos y la limitación de la finalidad deben incorporarse mediante ingeniería en los modelos y las canalizaciones en lugar de prometerse en la documentación. Un titular de CDPSE a menudo se convierte en la persona capaz de sentarse en una revisión de diseño y explicar, concretamente, cómo una funcionalidad cumplirá un requisito de privacidad. ISO 27701 acompaña con frecuencia a esta credencial: la norma define el sistema de gestión de la privacidad, y los ingenieros formados en CDPSE son quienes construyen los controles técnicos de los que ese sistema depende. CDPSE es una certificación de ISACA basada en la experiencia, lo que significa que se dirige a personas que ya trabajan en privacidad, seguridad o TI en lugar de a principiantes. Como otras credenciales de ISACA, conlleva requisitos de formación profesional continua para mantenerla vigente, reflejando la rapidez con que evolucionan tanto la tecnología como el panorama regulatorio. --- ## Certified Information Security Manager (CISM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cism **Last reviewed:** 2026-06-24 CISM es la credencial de ISACA para gestores de seguridad de la información: gobernanza, gestión de programas, gestión de riesgos, gestión de incidentes. El estándar de referencia para roles de liderazgo en seguridad, requerido en aproximadamente el 60% de las ofertas de CISO. Enfoque distinto al del CISSP: orientado a la gestión, menos técnico. ## Qué certifica el CISM El CISM es la certificación de ISACA dirigida a quienes gestionan la seguridad de la información en lugar de configurarla. Valida que usted es capaz de construir y dirigir un programa de seguridad, alinearlo con los objetivos del negocio y rendir cuentas de él ante la dirección y el consejo de administración. La credencial se organiza en torno a cuatro dominios profesionales: gobierno de la seguridad de la información, gestión de riesgos de seguridad de la información, desarrollo y gestión del programa de seguridad de la información, y gestión de incidentes de seguridad de la información. Esos cuatro ámbitos describen el trabajo real de un responsable de seguridad: marcar el rumbo, comprender y tratar el riesgo, entregar el programa que hace el trabajo y contener los incidentes cuando los controles fallan. La shortDefinition acierta al presentar el CISM como el referente por excelencia para los puestos de liderazgo en seguridad. En la práctica, esto significa que los responsables de contratación lo usan como indicio de que una persona «puede asumir una función de seguridad», no de que «puede fortificar un servidor». De un titular del CISM se espera que traduzca entre dos públicos: los equipos técnicos que operan los controles y los directivos que financian el riesgo y lo aceptan. Esa capa de traducción es el núcleo del rol, y por eso el discurso del CISM se apoya en el gobierno, las líneas de reporte y la aceptación del riesgo más que en las herramientas. ## CISM frente a CISSP: el enfoque de gestión La pregunta más habitual de los profesionales es en qué se diferencia el CISM del CISSP. Ambas son credenciales sénior y ambas tocan el gobierno, el riesgo y las operaciones, pero su centro de gravedad es distinto. El CISSP, de (ISC)squared, es más amplio y más técnico: ocho dominios que abarcan arquitectura, criptografía, seguridad de redes, seguridad del software y operaciones. Es la certificación natural para un profesional o arquitecto de seguridad. El CISM es más acotado y más directivo: cuatro dominios, todos vistos desde la perspectiva de quien rinde cuentas de un programa y un presupuesto, no de quien implementa los controles. **El CISM comparado con credenciales afines** | Credencial | Organismo | Enfoque principal | | --- | --- | --- | | CISM | ISACA | Gestionar un programa de seguridad: gobierno, riesgo, programa, incidentes | | CISSP | (ISC)squared | Profesional técnico amplio: ocho dominios, de la arquitectura a las operaciones | | CISA | ISACA | Auditoría y aseguramiento de los sistemas de información | | CRISC | ISACA | Identificación, evaluación y respuesta al riesgo de TI de la empresa | Dentro de la propia familia de ISACA, el CISM se sitúa junto al CISA y al CRISC. El CISA es la credencial del auditor, centrada en evaluar controles y aportar aseguramiento. El CRISC es la credencial del especialista en riesgos, centrada en identificar el riesgo de TI y responder a él. El CISM es la credencial del gestor, centrada en asumir la función que une el gobierno, el riesgo y las operaciones. Muchos líderes de seguridad acaban teniendo más de una, porque los roles se solapan a medida que se asciende. > **Una certificación, no un marco** El CISM no prescribe controles como lo hacen ISO 27001 o NIST. Certifica a la persona, no a la organización. Un titular del CISM dirigirá normalmente un SGSI ISO 27001 o un programa basado en NIST; la certificación dice que sabe liderar ese trabajo, no qué estándar elegir. ## Qué hace falta para obtener el CISM El CISM es una credencial condicionada por la experiencia, no solo un examen. ISACA exige a los candidatos aprobar el examen y acreditar experiencia laboral relevante en gestión de la seguridad de la información, una parte de ella dentro de los cuatro dominios. Existen exenciones limitadas para una parte del requisito de experiencia, y la certificación debe mantenerse después mediante formación profesional continua y la adhesión al código de ética profesional de ISACA. Ese requisito de mantenimiento es la razón por la que el CISM se mantiene vigente: los titulares acumulan horas de CPE en cada ciclo, en lugar de aprobar una vez y dormirse en los laureles. Para los profesionales que dudan si perseguirlo, este es el planteamiento honesto. Si su trayectoria apunta a dirigir una función de seguridad, asesorar a un consejo o ocupar un puesto de CISO, el CISM es la credencial que los responsables de contratación nombran con mayor frecuencia. Si su trabajo es la arquitectura y la ingeniería prácticas, el CISSP o una especialización técnica le servirán mejor. Ambas son complementarias y no rivales, y los líderes sénior a menudo poseen las dos. --- ## Certified Information Systems Auditor (CISA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cisa **Last reviewed:** 2026-06-24 CISA es la certificación de referencia en auditoría de sistemas de información, otorgada por ISACA desde 1978. Abarca cinco dominios: el proceso de auditoría, gobernanza, adquisición, operaciones y protección de activos. Es la credencial estándar en los encargos de las Big Four. Reconocida a nivel mundial; obligatoria en numerosos roles de auditoría interna y cumplimiento normativo en sectores regulados. ## Qué certifica realmente CISA CISA es la credencial que demuestra que puede auditar un sistema de información y defender la opinión a la que llega. La otorga ISACA y ha sido durante décadas la cualificación de referencia en auditoría de TI, razón por la cual constituye la expectativa por defecto en los encargos de las Big Four y el requisito que muchos empleadores regulados incluyen en las descripciones de puestos de auditoría interna y cumplimiento. La certificación no trata de operar la TI ni de protegerla. Trata de evaluar de forma independiente si los controles existen, si funcionan, y si la evidencia respalda esa conclusión. La distinción de praticante que conviene retener es que CISA es una credencial de aseguramiento, no de implementación. Quien posee CISM dirige un programa de seguridad. Quien posee CISA forma una opinión independiente sobre si ese programa, y el entorno de TI más amplio que lo rodea, está controlado. Esa independencia es la cuestión central: un auditor que construyó el control no puede ofrecer un aseguramiento creíble sobre él. CISA forma la mentalidad de evidencia y muestreo que mantiene la opinión defendible. ## Los cinco dominios de CISA El examen y el cuerpo de conocimientos se organizan en cinco dominios. Avanzan desde cómo se audita, pasando por cómo se gobierna la TI, hasta las tres áreas del ciclo de vida que un auditor debe ser capaz de evaluar: - Proceso de auditoría de sistemas de información. Planificación, alcance basado en riesgo, recopilación de evidencia, muestreo y elaboración de informes. La disciplina que hace auditables todos los demás dominios. - Gobierno y gestión de la TI. Estrategia, políticas, estructura organizativa, y cómo la empresa dirige y supervisa su TI. - Adquisición, desarrollo e implementación de sistemas de información. Si los proyectos, los cambios y los nuevos sistemas están controlados desde el caso de negocio hasta la puesta en producción. - Operación de sistemas de información y resiliencia del negocio. Operaciones diarias, gestión de servicios, copias de seguridad, continuidad y recuperación ante desastres. - Protección de los activos de información. Seguridad lógica y física, identidad y acceso, cifrado, y controles de protección de datos. > **CISA evalúa el juicio, no la memorización** El examen se basa en escenarios. Las preguntas plantean qué acción debería emprender primero un auditor, o qué hallazgo es más significativo, dada una situación. Se le evalúa por el juicio de auditoría y la priorización de riesgos, no por recitar listas de controles, razón por la cual la experiencia práctica de auditoría importa tanto como el estudio. ## El lugar de CISA junto a credenciales próximas CISA no existe de forma aislada en el catálogo de ISACA, y los profesionales la combinan habitualmente con otras. Los movimientos más frecuentes son laterales hacia el riesgo con CRISC, o ascendentes hacia el liderazgo en seguridad con CISM. Frente al mundo ISO, CISA y la credencial PECB Lead Auditor certifican ambas la competencia de auditoría, pero en ámbitos distintos: CISA es una cualificación amplia de auditoría de TI ligada a los dominios de ISACA, mientras que Lead Auditor se basa en ISO 19011 y se orienta a auditar un sistema de gestión específico, como un SGSI ISO 27001, a menudo como vía para convertirse en auditor acreditado de un organismo de certificación. **CISA comparada con credenciales próximas** | Credencial | Organismo | Enfoque principal | | --- | --- | --- | | CISA | ISACA | Aseguramiento amplio de auditoría de TI en cinco dominios | | CISM | ISACA | Gestión y gobierno de un programa de seguridad de la información | | CRISC | ISACA | Identificación, evaluación y respuesta al riesgo de TI | | Lead Auditor | PECB | Auditoría de un sistema de gestión específico según ISO 19011 | Obtener la credencial es más que aprobar el examen. ISACA exige experiencia profesional verificada en auditoría de TI, la adhesión a un código de ética profesional, y educación profesional continua para mantener activa la certificación. Ese requisito de experiencia es lo que da peso a CISA: confirma que quien la posee ha realizado realmente el trabajo, no solo lo ha estudiado. --- ## Certified in Risk and Information Systems Control (CRISC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/crisc **Last reviewed:** 2026-06-24 CRISC es la credencial de riesgo de ISACA para profesionales de riesgo en TI. Cubre identificación, evaluación, respuesta y seguimiento vinculados a los sistemas de información. Conecta el riesgo de negocio con el riesgo de TI. Complemento natural del CISA para auditores que pasan al ámbito del riesgo, y de ISO 27005 / ISO 31000 para profesionales formados en ISO que incorporan el vocabulario de ISACA. ## Qué certifica CRISC CRISC es la credencial de ISACA para profesionales que gestionan el riesgo de TI y de los sistemas de información, en lugar de auditarlo a posteriori. Valida que el titular puede ejecutar el ciclo de vida completo del riesgo sobre los activos tecnológicos: identificar la exposición, evaluar la probabilidad y el impacto, diseñar y recomendar una respuesta, y supervisar la posición residual a lo largo del tiempo. El rasgo distintivo de CRISC es la capa de traducción. Espera que el titular exprese una vulnerabilidad de base de datos o una configuración incorrecta en la nube en los términos que el registro de riesgos del negocio y el consejo utilizan realmente, de modo que el riesgo de TI se convierta en una entrada del riesgo empresarial, y no en una conversación paralela en un lenguaje distinto. Mientras que muchas certificaciones técnicas se detienen en los controles, CRISC presenta los controles como la consecuencia de una decisión de riesgo. Se espera que el titular parta del escenario de riesgo, del apetito y la tolerancia establecidos por la organización, y del coste del tratamiento, y luego justifique por qué existe un determinado control y qué deja sin abordar. Ese hilo riesgo-respuesta-control es la columna vertebral de la credencial y la razón por la que se sitúa junto al trabajo de gobernanza, y no en la seguridad puramente operativa. ## Dónde encaja CRISC entre las credenciales vecinas CRISC suele interpretarse como el paso natural siguiente para un titular de CISA. CISA demuestra que sabes auditar sistemas de información y juzgar si los controles están diseñados y operan de forma eficaz; CRISC demuestra que sabes gestionar el riesgo al que responden esos controles y decidir qué hacer al respecto. Los auditores que pasan de emitir hallazgos a fijar la estrategia de riesgo utilizan CRISC para hacer legible ese cambio ante los empleadores. Ambas comparten el vocabulario y el marco de gobernanza de ISACA, por lo que se emparejan habitualmente. Para los profesionales formados en ISO, CRISC añade el dialecto de ISACA sobre una metodología que ya aplican. Quien domina ISO 27005 o ISO 31000 ya realiza la identificación, el análisis, la evaluación, el tratamiento y la aceptación. CRISC no sustituye ese proceso; da a la misma persona los términos de ISACA, el enfoque del riesgo de TI empresarial y una credencial reconocida por empleadores que se estandarizan en ISACA en lugar de en ISO. Las metodologías son compatibles, y poseer ambas indica que sabes moverte entre los dos mundos de referencia. > **CISA describe, CRISC decide** Una lectura con mentalidad CISA de un hallazgo pregunta si el control funciona. Una lectura con mentalidad CRISC pregunta si el riesgo residual es aceptable dado el apetito, cuál debería ser la respuesta y quién es su responsable. La misma evidencia, una pregunta distinta. **Cómo se compara CRISC con las credenciales vecinas** | Credencial | Pregunta principal | Titular típico | | --- | --- | --- | | CRISC | ¿Cuál es el riesgo de TI y qué hacemos al respecto? | Gestor de riesgo de TI, responsable de riesgos | | CISA | ¿Están los controles diseñados y operando de forma eficaz? | Auditor de TI, auditoría interna | | ISO 27005 | ¿Cómo ejecutamos el proceso de riesgo de seguridad de la información? | Profesional de SGSI, analista de riesgos | ## Qué hacen realmente los titulares de CRISC En la práctica, un titular de CRISC trabaja cerca del punto donde se encuentran el riesgo tecnológico y la toma de decisiones del negocio. Las tareas recurrentes incluyen las siguientes. - Construir y mantener escenarios de riesgo de TI y un registro de riesgos que la función de riesgo empresarial más amplia pueda aprovechar. - Evaluar la probabilidad y el impacto, y luego contrastar el resultado con el apetito y la tolerancia declarados por la organización. - Recomendar una respuesta (aceptar, mitigar, transferir o evitar) y justificar la elección por el coste y el riesgo residual, no por una mera preferencia técnica. - Diseñar o especificar los controles de los sistemas de información que implementan una respuesta elegida, y definir los indicadores que muestran si se sostienen. - Supervisar los indicadores clave de riesgo e informar de la posición residual a los foros de gobernanza en términos de negocio. El hilo que recorre todo ello es la responsabilidad y la comunicación. CRISC tiene menos que ver con descubrir una nueva vulnerabilidad y más con decidir qué debería hacer la organización, garantizar que alguien sea responsable de esa decisión, y demostrar con el tiempo que el riesgo residual se mantuvo dentro del límite acordado. --- ## Certified in the Governance of Enterprise IT (CGEIT) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cgeit **Last reviewed:** 2026-06-24 CGEIT es la credencial de ISACA para profesionales sénior que asesoran sobre el gobierno de las TI empresariales: alineación estratégica, entrega de valor, optimización de riesgos y recursos. Sustentada en COBIT. Mercado más reducido que el de CISA / CISM, pero la credencial adecuada para CIOs, asesores de TI a nivel de consejo y consultores sénior. ## Qué certifica CGEIT CGEIT es la credencial de ISACA destinada a profesionales senior que asesoran sobre el gobierno de las TI corporativas o son responsables de él. El énfasis importa: se trata de gobierno, no de operaciones de seguridad ni de ejecución de proyectos. Se espera que un titular de CGEIT razone sobre la alineación estratégica entre las TI y los objetivos de negocio, la entrega de valor de las inversiones en TI, la optimización del riesgo y el uso responsable de los recursos. Son cuestiones propias del consejo de administración, y por eso la credencial está dirigida a CIO, responsables de gobierno de TI, asesores a nivel de consejo y consultores senior, y no a ingenieros o analistas operativos. La distinción con la que tropiezan los profesionales es la línea entre gobierno y gestión. El gobierno es la responsabilidad del consejo y de los directivos de evaluar opciones, fijar la dirección y supervisar si se obtienen los resultados. La gestión planifica, construye, opera y supervisa las actividades que materializan esa dirección. CGEIT valida que puede actuar en el lado del gobierno, diseñando y asegurando el sistema mediante el cual se dirigen las TI, en lugar de operar las TI en sí. ## El lugar de CGEIT entre las credenciales de ISACA CGEIT es la menor de las certificaciones insignia de ISACA por número de titulares, lo cual es una virtud y no un defecto. CISA valida la capacidad de auditar sistemas de información. CISM valida la capacidad de gestionar un programa de seguridad de la información. CGEIT valida la capacidad de gobernar las TI a nivel corporativo. Responden a preguntas distintas y convienen a etapas de carrera distintas: un auditor o un responsable de seguridad gana profundidad con CISA o CISM, mientras que un líder que avanza hacia una responsabilidad a nivel de consejo añade CGEIT. Suele buscarse más adelante en la carrera, porque la elegibilidad da peso a los años de experiencia real en gobierno, no a las horas de aula. **CGEIT comparado con credenciales vecinas de ISACA** | Credencial | Valida | Titular típico | | --- | --- | --- | | CGEIT | Gobierno de las TI corporativas a nivel de consejo de administración | CIO, responsable de gobierno de TI, asesor del consejo | | CISA | Auditoría de sistemas de información | Auditor de SI, profesional de aseguramiento | | CISM | Gestión de un programa de seguridad de la información | Responsable de seguridad, CISO | | CRISC | Gestión del riesgo de TI y del riesgo corporativo | Gestor de riesgos, propietario de controles | > **CGEIT es una credencial de liderazgo, no técnica** El examen y el requisito de experiencia evalúan si puede diseñar y asegurar un sistema de gobierno, alinear las TI con la estrategia y optimizar valor, riesgo y recursos. Da por supuesto que ya cuenta con la base técnica y que ahora es responsable de la dirección y no de la ejecución. ## Cómo lo sustenta COBIT CGEIT se asienta en COBIT, el marco de ISACA para el gobierno y la gestión de las TI corporativas. COBIT aporta la estructura en la que trabaja un titular de CGEIT: la separación entre objetivos de gobierno y de gestión, los componentes que hacen funcionar un sistema de gobierno como los procesos, las estructuras organizativas, las políticas, las competencias y la cultura, y los factores de diseño que adaptan ese sistema al contexto de una organización. En la práctica, un profesional certificado en CGEIT usa COBIT como modelo de referencia para evaluar dónde se encuentra el gobierno, diseñar dónde debería estar y racionalizar las normas ya en uso, como ISO 27001 o ITIL, en un conjunto coherente al servicio de los objetivos corporativos. Por eso también ambos suelen aprenderse juntos. Estudiar COBIT le da el marco; obtener el CGEIT demuestra que puede aplicar el pensamiento de gobierno a la estrategia, el valor, el riesgo y los recursos, al nivel en el que el consejo exige responsabilidad a las TI. Como ocurre con otras credenciales de ISACA, CGEIT se mantiene mediante formación profesional continua y la adhesión al código de ética profesional de ISACA. --- ## Chief Information Security Officer (CISO) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ciso **Last reviewed:** 2026-06-24 El CISO es el directivo responsable de la estrategia de seguridad de la información. Es propietario del registro de riesgos, dirige la respuesta a incidentes, informa al consejo de administración y aprueba el riesgo residual. Con NIS 2 y DORA, la responsabilidad es ahora explícita y personal. La función es de gobernanza, no de implementación; lo más difícil es traducir los conceptos técnicos al lenguaje del consejo. ## De qué responde realmente un CISO El CISO es el directivo responsable de la estrategia de seguridad de la información, y el énfasis está en responsable. Como lo expresa la shortDefinition, el trabajo es gobernanza, no implementación. Un CISO no configura cortafuegos ni escribe reglas de detección; decide dónde gasta la organización su presupuesto limitado de seguridad, qué riesgos trata y cuáles acepta, y cómo responde cuando algo falla. Los entregables cotidianos del puesto son un registro de riesgos, una hoja de ruta de programa, un plan de respuesta a incidentes y un conjunto de informes para el consejo, no una terminal. Esa distinción importa porque el liderazgo en seguridad se malinterpreta a menudo como un puesto de ingeniería sénior. No lo es. El CISO se sitúa en la frontera entre los equipos técnicos que operan los controles y los directivos que los financian y asumen las consecuencias. La parte más difícil del trabajo, como señala la shortDefinition, es la traducción ante el consejo: convertir una realidad técnica desbordante en un pequeño número de decisiones que un consejo pueda tomar realmente. Un CISO que no sabe explicar el riesgo residual en términos de negocio no puede hacer el trabajo, por sólida que sea su base técnica. ## Rendición de cuentas bajo NIS 2 y DORA Durante años el rol de CISO conllevó responsabilidad sin mucha rendición de cuentas formal. Eso ha cambiado. La shortDefinition es explícita: bajo NIS 2 y DORA la rendición de cuentas es ahora personal. NIS 2, la directiva europea sobre seguridad de las redes y de la información, eleva la supervisión de la ciberseguridad hasta el órgano de dirección de las entidades en alcance y hace que ese órgano sea responsable de aprobar y supervisar las medidas de gestión de riesgos de seguridad. DORA, el Digital Operational Resilience Act, hace lo equivalente para el sector financiero de la UE, situando la rendición de cuentas sobre resiliencia operativa firmemente en el órgano de dirección. El efecto práctico es que «la función de seguridad hace lo que puede» ya no es una postura defendible; un liderazgo nominalmente designado tiene que asumir por escrito las decisiones de riesgo. > **La rendición de cuentas no se puede delegar** Bajo NIS 2 y DORA, el órgano de dirección puede encargar el trabajo al CISO y al equipo de seguridad, pero conserva la responsabilidad del resultado. Un CISO que aprueba un riesgo residual está documentando una decisión que la organización ha aceptado formalmente, no trasladando la responsabilidad fuera del consejo. Por eso un CISO moderno dedica tanto tiempo a la documentación y a la cadencia de reporte. Aprobar el riesgo residual, informar al consejo sobre el panorama de amenazas y evidenciar que las medidas de gestión de riesgos se aprobaron al nivel adecuado ya no son extras de buena práctica. Es así como la organización demuestra que cumplió sus obligaciones legales. El rol ha pasado de «dirigir el equipo de seguridad» a «hacer que la gobernanza sea defendible». ## En qué se diferencia el CISO de los roles vecinos Al CISO se le confunde a menudo con las personas y funciones que lo rodean. Un responsable de seguridad o un propietario de programa certificado CISM dirige el programa de seguridad y puede reportar al CISO; el CISO fija la estrategia y carga con la rendición de cuentas ejecutiva sobre ella. Un líder de SOC es propietario de las operaciones de detección y respuesta; el CISO es propietario de la decisión sobre cuánta capacidad de detección financiará la organización y qué hará cuando el SOC escale un incidente mayor. Y cuando la organización opera un SGSI ISO 27001, el CISO suele ser el patrocinador ejecutivo de ese sistema de gestión más que su operador cotidiano. **El CISO comparado con roles adyacentes** | Rol | Enfoque principal | Reporta a | | --- | --- | --- | | CISO | Estrategia de seguridad, aceptación de riesgos, rendición de cuentas ante el consejo | CEO o consejo | | Responsable de seguridad | Dirigir el programa y el equipo de seguridad | A menudo el CISO | | Líder de SOC | Detección, monitorización, operaciones de respuesta a incidentes | CISO o responsable de seguridad | | DPO | Cumplimiento de protección de datos y derechos de las personas | Independiente, con acceso al consejo | Un emparejamiento que vale la pena separar con claridad es el CISO y el Delegado de Protección de Datos. Se solapan en incidentes que afectan a datos personales, pero son trabajos distintos. El DPO es un rol de cumplimiento y supervisión con una independencia legalmente protegida; el CISO es un directivo que es propietario de la estrategia de seguridad y se le mide por ella. En muchas organizaciones colaboran constantemente y reportan por líneas diferentes, precisamente porque el DPO debe poder cuestionar al negocio, incluida la función de seguridad. Para los profesionales en camino hacia el puesto, el encuadre honesto es que el rol de CISO recompensa el criterio y la comunicación más que las herramientas. La base técnica se da por supuesta; lo que hace que contraten a alguien y lo mantiene eficaz es la capacidad de asumir el riesgo, informar a un consejo y hacer defendible la rendición de cuentas bajo marcos como NIS 2 y DORA. --- ## Cláusulas Contractuales Tipo (SCC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/scc **Last reviewed:** 2026-06-24 Las SCCs son las cláusulas modelo aprobadas por la Comisión Europea para transferir datos personales a terceros países sin una decisión de adecuación. Las SCCs de 2021 sustituyeron a las versiones anteriores y exigen una Evaluación del Impacto de la Transferencia (TIA) desde Schrems II. Documentación obligatoria para cualquier organización que utilice proveedores SaaS fuera de la UE. ## Lo que realmente hacen las SCC Las cláusulas contractuales tipo son un contrato preredactado entre un exportador de datos en la UE y un importador en un país sin decisión de adecuación. Al firmarlas, el importador se compromete a obligaciones de nivel GDPR: limitación de la finalidad, seguridad, controles de transferencias ulteriores, derechos de los interesados y cooperación con la autoridad de control. Como la Comisión Europea ya ha aprobado la redacción, no es necesario negociar ni justificar las cláusulas en sí, motivo por el cual son el mecanismo de transferencia por defecto para casi cualquier relación SaaS, cloud o de subencargado fuera de la UE. Las cláusulas son modulares. Usted elige el módulo que se ajusta a la relación real: responsable a responsable, responsable a encargado, encargado a encargado, o encargado a responsable. Equivocarse de módulo es el error de redacción más común, porque las obligaciones y los puntos de acoplamiento para los subencargados difieren entre ellos. Las SCC también incluyen una cláusula de acoplamiento que permite que nuevas partes se incorporen a un conjunto existente, lo que mantiene manejables las largas cadenas de subencargados. > **Firmar no es la línea de meta** Las SCC de 2021 solo aportan una base legal para la transferencia si la protección que prometen es realmente efectiva sobre el terreno. Por eso Schrems II añadió una evaluación de impacto de la transferencia a cada conjunto de cláusulas que se firma. ## Por qué la TIA cambió las reglas del juego Antes de la sentencia Schrems II de 2020, firmar las SCC se consideraba suficiente por sí solo. El Tribunal de Justicia puso fin a ello. Dictaminó que los compromisos contractuales no pueden vincular a un gobierno extranjero, de modo que el exportador debe evaluar si el importador puede honrar genuinamente las cláusulas a la luz de la legislación local de vigilancia y acceso. Esa evaluación es la evaluación de impacto de la transferencia. En la práctica, se documenta el país de destino, las leyes que podrían obligar a la divulgación, la naturaleza y la sensibilidad de los datos, y si medidas complementarias como un cifrado robusto, la seudonimización o el procesamiento dividido cierran cualquier brecha que se detecte. Si la TIA concluye que el importador no puede cumplir los compromisos de las SCC y ninguna medida complementaria lo resuelve, la transferencia no debería realizarse sobre la base de las SCC. Aquí es donde las SCC difieren marcadamente de una decisión de adecuación: la adecuación es una constatación de la Comisión que elimina la carga caso por caso, mientras que las SCC trasladan esa carga a usted en cada transferencia. El EU-US Data Privacy Framework ofrece ahora una vía de adecuación para los importadores estadounidenses certificados, pero las SCC siguen siendo la herramienta de referencia para cualquier otro tercer país y para los proveedores estadounidenses que no están certificados. ## Lo que realmente hacen los profesionales Un proceso de SCC que funciona es repetible, no un ejercicio jurídico puntual. El patrón en el que se asienta la mayoría de los equipos es el siguiente. 1. Mapear la transferencia: identificar al exportador, al importador, las categorías de datos y el módulo correcto antes de tocar la plantilla. 1. Completar los anexos: las partes, la descripción del tratamiento y las medidas de seguridad técnicas y organizativas. Los anexos vagos son la parte que los reguladores cuestionan primero. 1. Ejecutar y documentar la TIA, incluyendo cualquier medida complementaria, y conservarla junto con las cláusulas firmadas. 1. Integrar las SCC en la incorporación de proveedores para que se firmen antes de que fluyan los datos, no de forma retroactiva después de que una auditoría detecte la brecha. 1. Revisar de nuevo cuando el proveedor cambie de subencargados, cuando el país de destino o sus leyes cambien, o con una cadencia fija. Las SCC se sitúan dentro de su narrativa más amplia de responsabilidad proactiva del GDPR. Remiten a los registros de las actividades de tratamiento, a la DPIA cuando es necesaria y a los controles de seguridad que usted ya se ha comprometido a aplicar. Tratadas como documentos vivos en lugar de como una firma recogida una sola vez, son la diferencia entre una transferencia que puede defender y otra que se derrumba en el momento en que un regulador o un interesado pregunta cómo protege los datos que salen de la UE. --- ## Commission nationale de l'informatique et des libertés (CNIL) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cnil **Last reviewed:** 2026-06-24 La CNIL es la autoridad francesa de protección de datos, fundada en 1978. Aplica el GDPR en Francia, emite decisiones vinculantes y sanciones, publica directrices (cookies, biometría, IA) y gestiona la herramienta PIA. Es una de las autoridades de control más activas de la UE; sus decisiones sientan precedente a escala europea. La CNIL es la autoridad de control que convierte el derecho europeo de protección de datos en consecuencias concretas dentro de Francia. Es anterior al RGPD en varias décadas, razón por la cual su cometido va más allá de la mera sanción: asesora al gobierno sobre los proyectos de ley, acredita y audita, difunde orientación dirigida al público y actúa como punto de contacto único tanto para los interesados que presentan reclamaciones como para los responsables del tratamiento que notifican violaciones. Para una organización francesa, la CNIL es la cara práctica del cumplimiento. Es el organismo que responde a sus preguntas, el que le inspecciona y el que decide si un problema termina en una advertencia o en una multa. ## Qué hace realmente la CNIL Entienda la CNIL como cuatro funciones que se solapan, más que como un único regulador. Primero, produce orientaciones que se convierten en la referencia operativa en Francia: sus normas sobre cookies, sus marcos sobre biometría y contratación, y sus tomas de posición sobre inteligencia artificial se leen como lo que es una buena práctica, incluso allí donde el texto del RGPD es general. Segundo, conduce el diálogo de supervisión, gestionando reclamaciones, controlando a las organizaciones mediante revisión documental e inspección in situ, y emitiendo requerimientos formales de cumplimiento. Tercero, sanciona, con la potestad de imponer medidas correctoras vinculantes y multas administrativas. Cuarto, dota a los profesionales de herramientas, la más visible el software PIA utilizado para estructurar una evaluación de impacto relativa a la protección de datos. La mayoría de los responsables del tratamiento nunca ven la versión de la CNIL de las multas que ocupan titulares. Ven la versión del diálogo: una solicitud de documentos, una pregunta sobre la base jurídica, un requerimiento formal que fija un plazo para corregir algo. Poner en orden su registro de actividades de tratamiento, sus evaluaciones de impacto y sus disposiciones relativas al DPO es lo que mantiene la interacción en ese registro más moderado. > **La orientación es el suelo, no el techo** Cuando la CNIL publica un marco, se espera que las organizaciones francesas lo sigan o documenten una razón defendible para apartarse de él. Leer su orientación actual sobre cookies, biometría e IA sale más barato que descubrir las expectativas de la CNIL durante una inspección. ## CNIL, RGPD y la ventanilla única de la UE La CNIL no escribe la ley que hace cumplir. El RGPD es el reglamento; la CNIL es una de las autoridades de control nacionales que lo aplican. Esa distinción importa para el tratamiento transfronterizo. Bajo el mecanismo de ventanilla única, una organización con su establecimiento principal en Francia trata principalmente con la CNIL como autoridad principal, y la CNIL se coordina con otras autoridades europeas a través de los procedimientos de cooperación y coherencia en lugar de actuar de forma aislada. Para el tratamiento puramente nacional, la CNIL actúa por su cuenta. La CNIL es además una de las autoridades más activas de la UE, por lo que su razonamiento y sus decisiones sancionadoras se estudian mucho más allá de Francia como indicación de hacia dónde se dirige la aplicación europea. Aquí es también donde los roles que la rodean encajan en su sitio. El RGPD crea obligaciones; el DPO es el rol dentro de la organización que supervisa el cumplimiento y sirve de punto de contacto con la autoridad; la CNIL es la autoridad al otro extremo de ese contacto. Un profesional capaz de explicar cómo se relacionan esos tres rara vez es el que queda en evidencia durante una inspección. ## Qué hacen los profesionales con la CNIL En la práctica, trabajar bien con la CNIL es sobre todo preparación más que reacción. Los hábitos concretos son constantes en las organizaciones francesas maduras. - Relacione la orientación actual de la CNIL con su propio tratamiento, en especial cookies, biometría, contratación y cualquier decisión basada en IA, y mantenga esa relación actualizada. - Mantenga las pruebas de responsabilidad proactiva que la CNIL pide ver primero: el registro de actividades de tratamiento, las evaluaciones de impacto realizadas y la base documentada de cada finalidad del tratamiento. - Utilice la herramienta PIA de la CNIL para estructurar las evaluaciones de impacto de modo que el resultado hable el propio lenguaje de la autoridad. - Conozca de antemano su vía de notificación de violaciones, para que un incidente notificable se convierta en un proceso en lugar de en una carrera contrarreloj. - Trate un requerimiento formal como un proyecto marcado por un plazo, no como una negociación, y documente cada paso que da para cumplir. Nada de esto es exótico. Es la misma disciplina de responsabilidad proactiva que exige el RGPD, organizada de modo que el único organismo con más probabilidades de pedirla pueda recibir respuesta de forma rápida y creíble. --- ## Cyber Resilience Act (CRA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cra **Last reviewed:** 2026-06-24 El Cyber Resilience Act es el reglamento de la UE que impone obligaciones de seguridad de referencia a los productos de hardware y software con elementos digitales comercializados en Europa. Obligaciones del fabricante durante el ciclo de vida: seguridad desde el diseño, gestión de vulnerabilidades, SBOM, cinco años de parches. Adoptado a finales de 2024, aplicable desde diciembre de 2027. Combinar con NIS 2 (perspectiva organizativa) y AI Act (perspectiva de modelos). ## Lo que realmente regula el Cyber Resilience Act El Cyber Resilience Act impone obligaciones de seguridad al producto, no solo a la organización que lo opera. Todo lo que se vende en la UE y contiene elementos digitales, es decir, hardware o software con una conexión de datos, entra en su ámbito: dispositivos de consumo conectados, controladores industriales, sistemas operativos, bibliotecas, aplicaciones móviles e incluso el firmware integrado en un componente. La parte regulada es el operador económico que introduce el producto en el mercado, de modo que los fabricantes asumen la carga principal, mientras que los importadores y distribuidores quedan sujetos a obligaciones de verificación. Esto supone un desplazamiento de la responsabilidad. Durante años el comprador heredaba el riesgo del software inseguro; el CRA traslada una base definida de responsabilidad a quien construye y vende el producto. Como regula productos en lugar de entidades, el CRA alcanza a pequeños proveedores y componentes abiertos que ninguna ley de seguridad organizativa tocaría jamás. Un fabricante de firmware sin oficina en la UE igualmente tiene que cumplir si el dispositivo llega a un estante europeo. Ese enfoque por producto es lo más importante que hay que comprender antes de leer cualquier otra cosa sobre él. ## Las obligaciones que vinculan a un fabricante El CRA se construye en torno a un ciclo de vida. Un producto tiene que ser seguro cuando se entrega y mantenerse soportable durante el tiempo que razonablemente se espera que esté en uso, que el reglamento fija en un periodo de soporte base de aproximadamente cinco años para la gestión de vulnerabilidades. Las obligaciones concretas se agrupan en dos conjuntos. - Seguridad desde el diseño y por defecto: entregar sin vulnerabilidades explotables conocidas, reducir al mínimo la superficie de ataque, proteger la confidencialidad y la integridad de los datos, y proporcionar una configuración predeterminada segura para que el producto no sea inseguro nada más sacarlo de la caja. - Gestión de vulnerabilidades durante el periodo de soporte: mantener un proceso de divulgación coordinada, proporcionar un Software Bill of Materials para que los componentes que hay dentro del producto queden documentados, entregar actualizaciones de seguridad con prontitud y, cuando sea factible, de forma automática, y notificar las vulnerabilidades explotadas activamente y los incidentes graves a ENISA dentro de los plazos del reglamento. La conformidad se demuestra del modo en que la UE trata el resto de la legislación de seguridad de productos: una evaluación proporcionada a la clase de riesgo del producto, documentación técnica y marcado CE que señala que se ha alcanzado la base de seguridad. Las categorías de productos de mayor riesgo, denominadas importantes o críticas, se enfrentan a una evaluación más estricta, a veces por un tercero, en lugar de una autodeclaración. > **El SBOM es ahora un entregable, no un detalle opcional** El CRA convierte el Software Bill of Materials, que era una aspiración de los equipos de seguridad, en una exigencia regulatoria. Los fabricantes necesitan conocer y documentar qué hay dentro de sus productos, porque son responsables de las vulnerabilidades de esos componentes durante todo el periodo de soporte, incluidas las dependencias de terceros y de código abierto. ## Cómo se sitúa junto a NIS 2 y la AI Act Estos tres instrumentos de la UE son deliberadamente complementarios y los profesionales no deben confundir sus ámbitos. El CRA es el ángulo del producto: hace seguro lo que vendes. NIS 2 es el ángulo organizativo: obliga a las entidades esenciales e importantes a gestionar el riesgo cibernético, gobernar la seguridad y notificar incidentes a nivel de empresa. La AI Act es el ángulo del modelo: rige cómo se construyen y se introducen en el mercado los sistemas de IA, en especial los de alto riesgo. Un dispositivo industrial conectado vendido por un operador regulado que incorpora un componente de IA puede afectar a los tres a la vez, cada uno desde una dirección distinta. **Comparación de los instrumentos europeos de seguridad digital** | Instrumento | Qué regula | A quién vincula | | --- | --- | --- | | Cyber Resilience Act | Seguridad de los productos con elementos digitales | Fabricantes, importadores, distribuidores | | NIS 2 | Gestión y notificación del riesgo cibernético a nivel organizativo | Entidades esenciales e importantes | | AI Act | Desarrollo e introducción en el mercado de sistemas de IA | Proveedores y responsables del despliegue de IA | La consecuencia práctica es que la preparación para el CRA es en gran medida un programa de ingeniería y de gobernanza de producto, no un trámite documental añadido a un SGSI existente. Los equipos que ya practican la divulgación coordinada de vulnerabilidades, mantienen inventarios de dependencias y parchean con una cadencia previsible tienen gran parte del camino recorrido. Los equipos que entregan y se olvidan son los que más trabajo tienen por delante, porque la obligación de dar soporte y parchear durante años es precisamente lo que una cultura de entregar y pasar a otra cosa busca evitar. El reglamento se adoptó a finales de 2024 y sus obligaciones principales se aplican a partir de diciembre de 2027, lo que deja un margen definido para implantar los procesos de gestión de vulnerabilidades y de SBOM antes de que sean exigibles. --- ## Cybersecurity Maturity Model Certification (CMMC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/cmmc **Last reviewed:** 2026-06-24 CMMC es el modelo de madurez en ciberseguridad que el Departamento de Defensa de Estados Unidos impone a sus contratistas que gestionan información de contratos federales e información no clasificada controlada. CMMC 2.0 se redujo a tres niveles (Foundational, Advanced, Expert) alineados con NIST SP 800-171 y 800-172. Si vende al DoD o forma parte de su cadena de suministro, está en el ámbito de aplicación. ## Qué cambia realmente CMMC para un contratista Durante años, el Department of Defense estadounidense pidió a sus proveedores que protegieran la información sensible y confió en que lo hicieran. Los contratistas autodeclaraban que cumplían las salvaguardas exigidas, y la brecha entre lo que se afirmaba y lo que estaba implementado solo salía a la luz tras una brecha de seguridad. CMMC cierra esa brecha al convertir los requisitos de protección existentes en una certificación verificable. La sustancia de los controles no cambió tanto como la carga de la prueba: donde antes firmabas una declaración, ahora posees una certificación que, tras una evaluación, confirma que tus prácticas están realmente implantadas. Si manejas Federal Contract Information o Controlled Unclassified Information en cualquier punto de la cadena de suministro del DoD, este es el mecanismo que decide si puedes seguir licitando. El modelo importa mucho más allá de las fronteras estadounidenses. Los proveedores europeos que subcontratan con contratistas principales estadounidenses, fabrican componentes de defensa o tratan CUI por cuenta de un programa del DoD heredan la misma obligación. CMMC no es un marco que se adopta voluntariamente por buena higiene; es una puerta contractual. Sin certificación al nivel que exige tu contrato, no hay adjudicación. Eso es lo que lo distingue de un modelo de madurez voluntario y lo sitúa en la misma categoría práctica que un requisito regulatorio: el cumplimiento es el precio del acceso al mercado. ## Los tres niveles y lo que abarcan CMMC 2.0 simplificó un esquema anterior de cinco niveles en tres, cada uno vinculado a la sensibilidad de los datos que manejas y a una línea base NIST existente. El nivel 1 (Foundational) cubre la protección básica de la Federal Contract Information y se basa en las prácticas de las normas federales de adquisición, verificadas mediante autoevaluación anual. El nivel 2 (Advanced) protege la Controlled Unclassified Information y se alinea directamente con NIST SP 800-171, el catálogo de controles ya exigido a los contratistas que manejan CUI; según el contrato, se confirma mediante una evaluación de terceros. El nivel 3 (Expert) es para los programas más sensibles y añade los requisitos reforzados de NIST SP 800-172 para defenderse de las amenazas persistentes avanzadas, evaluado por el propio gobierno. **Niveles CMMC 2.0** | Nivel | Datos protegidos | Línea base | Evaluación | | --- | --- | --- | --- | | Nivel 1 — Foundational | Federal Contract Information (FCI) | Requisitos de protección básica | Autoevaluación anual | | Nivel 2 — Advanced | Controlled Unclassified Information (CUI) | NIST SP 800-171 | Evaluación de terceros (o autoevaluación) | | Nivel 3 — Expert | CUI de alto valor, exposición a APT | NIST SP 800-171 más 800-172 | Evaluación dirigida por el gobierno | La idea clave es que CMMC no inventa tanto nuevos controles como que impone los que los contratistas ya estaban obligados a cumplir. Un proveedor que ha implementado de verdad NIST SP 800-171 tiene casi todo el camino hecho hacia el nivel 2; el trabajo que queda consiste en producir la evidencia, cerrar las prácticas que se daban por supuestas pero nunca se operacionalizaron, y superar una evaluación realizada por alguien que no eres tú. ## El lugar de CMMC junto a NIS 2 e ISO 27001 Es fácil archivar CMMC, NIS 2 e ISO 27001 en el mismo cajón, pero responden a preguntas distintas. ISO 27001 certifica que operas un sistema de gestión de la seguridad de la información basado en el riesgo; es voluntario, internacional e indiferente a de quién sean los datos que posees. NIS 2 es legislación europea que impone deberes de seguridad y de notificación de incidentes a las entidades esenciales e importantes de sectores críticos. CMMC es más estrecho y más específico: un requisito de contratación pública del gobierno estadounidense dirigido a una sola cadena de suministro, mapeado a conjuntos fijos de controles NIST en lugar de a tu propia evaluación de riesgos. Una organización ya certificada en ISO 27001 habrá construido una disciplina de gestión que facilita el esfuerzo de CMMC, pero las certificaciones no son intercambiables y una no satisface a la otra. > **La autodeclaración ha terminado** La clave de CMMC es que una firma ya no basta en los niveles superiores. Si tu oferta depende de proteger CUI, planifica una evaluación externa y construye el rastro de evidencia desde el principio en lugar de reconstruirlo la semana anterior. --- ## Data Protection Officer (DPO) **URL:** https://cyberacademy.net/es/resources/encyclopedia/dpo **Last reviewed:** 2026-06-24 El DPO es el rol exigido por el GDPR que supervisa el cumplimiento, asesora al responsable del tratamiento y actúa como punto de contacto con la autoridad de control. Es obligatorio para las autoridades públicas y para los tratamientos que requieren una supervisión sistemática a gran escala o datos de categorías especiales. La independencia y el acceso a la dirección son los dos aspectos que los auditores verifican en la práctica. ## Para qué sirve la figura El Data Protection Officer es la persona que una organización designa para mantener la integridad de su tratamiento de datos personales conforme al GDPR. Su función no es dirigir proyectos de privacidad ni dar el visto bueno a la conformidad, sino supervisar si la organización hace lo que la ley y sus propias políticas exigen, asesorar al responsable y al encargado del tratamiento, formar y concienciar, y ser el punto de contacto único para la autoridad de control y para los interesados que deseen ejercer sus derechos. El DPO informa y asesora, pero la responsabilidad del tratamiento sigue recayendo en el responsable. Un DPO es obligatorio en tres situaciones: cuando el tratamiento lo realiza una autoridad pública, cuando las actividades principales requieren una observación habitual y sistemática de personas a gran escala, y cuando las actividades principales implican el tratamiento a gran escala de categorías especiales de datos, como datos de salud, biométricos o relativos a condenas penales. Las organizaciones que quedan fuera de estos supuestos pueden designar igualmente un DPO de forma voluntaria, y muchas lo hacen porque les proporciona un responsable interno claro para las cuestiones de privacidad. ## Independencia y acceso, los dos puntos que comprueban los auditores Cuando un regulador o un auditor interno examina la función del DPO, dos puntos deciden si es real o cosmética. El primero es la independencia. El DPO no debe recibir instrucciones sobre cómo desempeñar su labor, no puede ser destituido ni sancionado por hacer bien su trabajo, y no debe quedar en una posición en la que audite sus propias decisiones. Por eso un DPO normalmente no debería ser también el CISO, el responsable de TI o el responsable de marketing, porque esos cargos definen los fines y los medios del tratamiento que el DPO debe escrutar. El segundo es el acceso. El DPO debe rendir cuentas ante el más alto nivel de dirección y participar, de forma temprana y adecuada, en todas las cuestiones relativas a la protección de datos personales. > **El conflicto de intereses es el hallazgo clásico** Designar a un DPO que además es propietario de los sistemas que se supone debe supervisar es uno de los motivos más habituales por los que una autoridad de control concluye que la función no es realmente independiente. Mantenga al DPO al margen de las decisiones sobre los fines y los medios del tratamiento. - Supervisa el cumplimiento del GDPR y de las políticas internas de protección de datos. - Asesora sobre las evaluaciones de impacto relativas a la protección de datos (DPIA) y ayuda a revisarlas. - Coopera con la autoridad de control y actúa como su punto de contacto. - Gestiona la comunicación con los interesados sobre sus derechos. ## Cómo encaja el DPO con conceptos vecinos El DPO es una persona y un deber, no un marco de control. El GDPR es el reglamento que crea la figura y fija sus funciones. La DPIA es uno de los instrumentos sobre los que asesora el DPO, una evaluación estructurada que se realiza antes de iniciar un tratamiento de alto riesgo. ISO 27701 es la norma de gestión de la información de privacidad frente a la que una organización puede certificarse, y una función de DPO bien gestionada se ajusta de forma natural a sus requisitos sin ser lo mismo. La CDPSE es una certificación profesional que valida que un ingeniero de privacidad o un DPO sabe integrar la privacidad en los sistemas. Un DPO puede ser un empleado o un proveedor de servicios externo, y un grupo de empresas puede designar un único DPO siempre que esa persona siga siendo accesible desde cada establecimiento y conserve suficiente independencia y recursos para cubrirlos a todos. --- ## Declaración de Aplicabilidad (SoA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/soa **Last reviewed:** 2026-06-24 La SoA es el documento controlado que indica al auditor qué controles del Anexo A se aplican, por qué y dónde se encuentra la evidencia. Obligatoria según ISO 27001. La inconsistencia entre la SoA, el plan de tratamiento de riesgos y las operaciones reales es la causa más frecuente de no conformidades en la auditoría de etapa 2. ## Por qué ISO 27001 hace obligatorio el SoA La declaración de aplicabilidad es el puente entre su trabajo sobre los riesgos y los controles que un auditor inspeccionará realmente. ISO/IEC 27001 deja deliberadamente abierto el cuerpo de la norma sobre qué controles debe ejecutar, porque la respuesta correcta depende de su contexto y de sus riesgos. El SoA es donde usted cierra esa brecha: para cada control de referencia del Anexo A, registra si aplica, la justificación para incluirlo o excluirlo, si ya está implementado y dónde reside la evidencia que lo respalda. Es uno de los pocos documentos que la norma nombra explícitamente como salida requerida, razón por la cual ninguna auditoría de certificación se desarrolla sin él. Una forma útil de entenderlo es que el SoA convierte un catálogo de controles genérico en una declaración sobre su organización específicamente. El conjunto de referencia del Anexo A es el mismo para todos. Su SoA no lo es. Dos empresas certificadas de tamaño similar pueden excluir legítimamente controles diferentes, porque sus apreciaciones de riesgos y su contexto operativo difieren. El documento existe para hacer esas elecciones visibles y defendibles en lugar de implícitas. ## Cómo se relaciona el SoA con la apreciación de riesgos y el tratamiento de riesgos El SoA no existe por sí solo. Es el producto posterior de la apreciación de riesgos y del plan de tratamiento de riesgos, y los tres deben concordar. La apreciación de riesgos identifica qué podría salir mal. El plan de tratamiento de riesgos decide qué hacer con cada riesgo, incluido qué controles aplicar. El SoA declara entonces, control por control, qué significa esa decisión frente al conjunto de referencia del Anexo A. Cuando un auditor lee el SoA, en realidad está comprobando que la línea que va de un riesgo documentado a una decisión de tratamiento, luego a un control aplicado, y luego a evidencia real, se sostiene de principio a fin. > **La desviación es el hallazgo clásico de la etapa 2** La no conformidad más común en la auditoría de etapa 2 es la incoherencia entre el SoA, el plan de tratamiento de riesgos y lo que la organización hace realmente. Un control marcado como aplicable e implementado en el SoA, sin evidencia ni realidad operativa detrás, es peor que una exclusión honesta. Concilie los tres antes de que el auditor lo haga por usted. Las exclusiones merecen un cuidado especial. Marcar un control como no aplicable es legítimo, pero solo con un motivo declarado y vinculado a su contexto. «No desarrollamos software internamente» es una base defendible para acotar ciertos controles de desarrollo. «No llegamos a hacerlo» no es una exclusión, es una carencia. Los auditores indagan las exclusiones precisamente porque es ahí donde las organizaciones a veces esconden trabajo sin terminar. ## Lo que los profesionales mantienen realmente Tratar el SoA como un registro vivo en lugar de una hoja de cálculo puntual es lo que separa una auditoría de seguimiento tranquila de una carrera contrarreloj. En la práctica, mantenerlo bien se ve así: 1. Mantenga una fila por cada control del Anexo A, con aplicabilidad, justificación, estado de implementación y un puntero a la evidencia que un auditor pueda seguir sin usted en la sala. 1. Vuelva a generar el SoA siempre que cambie la apreciación de riesgos o el plan de tratamiento, para que los tres documentos nunca diverjan en silencio. 1. Vincule cada puntero de evidencia a algo real y actual: una política, una configuración, un ticket, un registro, no una promesa de producirlo más adelante. 1. Revise el documento con una cadencia fija y en la revisión por la dirección, no solo en las semanas previas a una auditoría. 1. Al transicionar entre versiones de la norma, reasigne el SoA frente al conjunto de controles revisado y confirme que nada se perdió entre los controles fusionados o recién introducidos. Hecho así, el SoA deja de ser papeleo de auditoría y se convierte en el índice de todo su sistema de gestión de la seguridad de la información. Es el primer documento que un auditor experimentado pide, porque le indica dónde reside todo lo demás. --- ## Defensa en profundidad **URL:** https://cyberacademy.net/es/resources/encyclopedia/defense-in-depth **Last reviewed:** 2026-06-24 La defensa en profundidad es el principio de superponer controles para que ningún fallo aislado comprometa el sistema. Red, endpoint, aplicación, datos, personas, física: cada capa frena al atacante, eleva el coste y gana tiempo de detección. Principio fundamental desde los años noventa. Los auditores esperan verlo; los proveedores adoran vender capas adicionales. ## Por qué la superposición supera a un único muro robusto La defensa en profundidad parte de una suposición pesimista: cualquier control acabará fallando tarde o temprano. Un cortafuegos mal configurado, un parche que llega tarde, un correo de phishing que alcanza su objetivo, una credencial que se filtra. Si su seguridad descansa sobre una única barrera, ese único fallo significa el fin de la partida. Superponer controles significa que el atacante que franquea el perímetro se topa después con la protección de los endpoints, luego con redes segmentadas, luego con controles de aplicación, luego con datos cifrados, luego con una supervisión que observa todo el recorrido. Cada capa es independiente, de modo que la probabilidad de que todas fallen a la vez es mucho menor que la probabilidad de que falle una sola. El valor para el profesional no es solo la prevención, es el tiempo y la visibilidad. Cada capa que el atacante debe vencer le cuesta esfuerzo, genera ruido y crea una oportunidad para que su equipo de detección y respuesta advierta la intrusión antes de que llegue a los datos que importan. La defensa en profundidad consiste tanto en ganar tiempo de detección como en detener la brecha de plano. ## Las capas y qué reside en cada una Los profesionales suelen pensar en capas concéntricas en lugar de en una lista plana de productos. El objetivo es la cobertura de todas las categorías, no comprar todas las herramientas de una misma categoría. Una forma habitual de organizar las capas: - Física: instalaciones cerradas, tarjetas de acceso y controles de equipos, para que un atacante no pueda simplemente caminar hasta el hardware. - Personas: formación de concienciación, simulaciones de phishing y procesos claros, porque los usuarios son a la vez un objetivo y un control. - Red: segmentación, cortafuegos e inspección del tráfico, para que un punto de apoyo en una zona no otorgue acceso a todo el conjunto. - Endpoint: refuerzo, EDR y gestión de parches en las máquinas donde los ataques se ejecutan realmente. - Aplicación: desarrollo seguro, validación de entradas y controles de autenticación en la capa de software. - Datos: cifrado en reposo y en tránsito, clasificación y controles de acceso, para que el propio activo permanezca protegido aunque se vulnere una capa superior. > **Capas, no duplicación** La defensa en profundidad significa controles independientes repartidos por distintas categorías, no tres cortafuegos de tres proveedores. Apilar herramientas redundantes en una capa mientras se deja otra al descubierto es un error común y costoso. Asigne sus controles a las capas y busque las brechas, no los solapamientos. ## Cómo se relaciona con el zero trust y el mínimo privilegio La defensa en profundidad es el principio más antiguo y amplio. El zero trust y el mínimo privilegio son expresiones modernas más afinadas del mismo instinto. El mínimo privilegio consiste en dar a cada identidad solo el acceso que necesita, lo que limita hasta dónde puede llegar cualquier cuenta comprometida, añadiendo en la práctica una capa dentro del sistema en lugar de alrededor de él. El zero trust descarta la suposición de que cualquier cosa dentro del perímetro es de confianza, verificando cada solicitud de forma continua. Allí donde la defensa en profundidad clásica solía suponer una cáscara exterior dura con un interior más blando, el zero trust lleva la verificación a cada frontera. Son complementarios: un programa maduro utiliza la defensa en profundidad como arquitectura y el zero trust como modelo operativo que elimina el centro blando y esponjoso. En las normas y las auditorías, la idea está en todas partes incluso cuando la expresión no lo está. El Anexo A de ISO/IEC 27001 distribuye los controles entre temas organizativos, de personas, físicos y tecnológicos, lo que es defensa en profundidad con otro nombre. Los marcos del NIST y los CIS Controls están estructurados de modo que ninguna salvaguarda individual soporte toda la carga. Los auditores esperan ver controles en capas con una justificación documentada, y tratan un punto único de fallo como una no conformidad, no como una decisión de diseño. --- ## Denegación de Servicio Distribuida (DDoS) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ddos **Last reviewed:** 2026-06-24 DDoS es el ataque que inunda un servicio desde múltiples fuentes para agotar su capacidad. Puede ser volumétrico, de protocolo o de capa de aplicación. La mitigación se ha convertido en un commodity (Cloudflare, Akamai, AWS Shield). La pregunta de riesgo ya no es «¿podemos bloquearlo?», sino «¿están los servicios críticos enrutados a través de la protección, incluidos los de API que nunca aparecen en los dashboards?». ## Lo que realmente hace un ataque de denegación de servicio distribuido Un ataque de denegación de servicio tiene un único objetivo: dejar un servicio indisponible para quienes dependen de él. La versión distribuida, el DDoS, lo logra generando el tráfico desde muchas máquinas a la vez, a menudo una botnet de dispositivos comprometidos, servidores secuestrados o infraestructura de ataque alquilada. Como la carga llega desde miles de direcciones distintas, no se puede simplemente bloquear a un único infractor, y es la enorme cantidad de fuentes lo que permite al atacante saturar una capacidad que una sola máquina nunca podría alcanzar. El objetivo no necesita ser vulnerado ni sufrir un robo de datos. Solo necesita quedar fuera de línea, lo que convierte al DDoS en un ataque contra la disponibilidad y no contra la confidencialidad o la integridad. Los profesionales suelen clasificar el DDoS en tres capas, porque la capa dicta la defensa. Los ataques volumétricos intentan saturar el ancho de banda del propio enlace, recurriendo con frecuencia a la amplificación, donde una pequeña solicitud falsificada desencadena una respuesta de gran tamaño dirigida a la víctima. Los ataques de protocolo agotan el estado en los equipos de red y los servidores, por ejemplo dejando conexiones medio abiertas que nunca se completan. Los ataques a la capa de aplicación son los más silenciosos: envían solicitudes que parecen legítimas, como llamadas repetidas a un punto de acceso de búsqueda o a una página de inicio de sesión, y agotan la aplicación en lugar del canal. Esta última categoría es la más difícil de separar de los usuarios reales. ## Por qué la mitigación ya no es la parte difícil Detener el tráfico DDoS se ha convertido en un servicio común. Grandes proveedores como Cloudflare, Akamai y AWS Shield absorben los ataques en el borde de redes enormes, encajando las avalanchas volumétricas muy por encima del cliente y filtrando los abusos de protocolo y de aplicación mediante depuración del tráfico y limitación de tasa. Para la mayoría de las organizaciones, la pregunta técnica de si un ataque puede bloquearse tiene un sí seguro, siempre que el tráfico se enrute a través de esa protección. La pregunta más difícil, y la que debería plantear una función de riesgos, es de cobertura más que de capacidad. La brecha que duele es el activo que nadie enrutó a través del escudo. Un sitio de marketing público está detrás de la CDN, pero la API que llama la aplicación móvil, la dirección IP de origen heredada que nunca se desmanteló, el punto de acceso de integración con un socio o el servicio regional levantado por otro equipo pueden resolver directamente al origen, eludiendo por completo la protección. Los atacantes encuentran esas rutas directas y apuntan ahí. Una defensa DDoS eficaz es, por tanto, ante todo un problema de inventario y enrutamiento: conocer cada servicio expuesto a internet, confirmar que cada uno está realmente detrás de la mitigación y demostrar que no se puede llegar al origen rodeándola. > **La API desprotegida es la verdadera exposición** La mitigación solo funciona para el tráfico que la atraviesa. Los servicios que tumban a una organización suelen ser los que nunca se ven en un panel: una dirección IP de origen directa, un punto de acceso de API o un subdominio olvidado que resuelve rodeando la protección. Cartografíe cada activo expuesto a internet y luego demuestre que cada uno se enruta a través del escudo. ## Dónde encaja el DDoS en la continuidad y las normas Como el DDoS ataca la disponibilidad, pertenece a la misma conversación que la gestión de la continuidad del negocio. Un sistema de gestión de la seguridad de la información alineado con ISO/IEC 27001 trata la disponibilidad como una de las tres propiedades que protege, y un escenario de denegación de servicio es una entrada de manual para un análisis de impacto en el negocio: cuánto tiempo puede estar caído cada servicio, qué depende de él y cuál es la alternativa. La respuesta rara vez es un único control. Combina mitigación en sentido ascendente, un manual de respuesta a incidentes con contactos nombrados en el proveedor de mitigación y disposiciones de continuidad para el periodo en que se absorbe un ataque. Lo que los profesionales hacen realmente, más allá de comprar mitigación, es ensayar y verificar. Mantienen un inventario preciso de los servicios expuestos a internet, confirman que cada uno está detrás de la protección y comprueban que no se puede llegar al origen de forma directa. Ajustan los límites de tasa y las páginas de desafío para los abusos de la capa de aplicación, ya que esos ataques imitan el tráfico real y no pueden resolverse solo con ancho de banda. Redactan la ruta de escalado antes de un incidente, de modo que durante una avalancha nadie ande buscando el número de teléfono correcto. Y tratan un evento DDoS como un ejercicio de continuidad, con umbrales claros para activar el plan, comunicarse con los clientes y restablecer los servicios una vez que el tráfico amaina. --- ## Digital Operational Resilience Act (DORA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/dora **Last reviewed:** 2026-06-24 DORA es el reglamento de la UE que impone un marco de resiliencia unificado a las entidades financieras y sus proveedores críticos de TIC. Cinco pilares: gestión del riesgo TIC, notificación de incidentes, pruebas de resiliencia incluidas las TLPT, riesgo de terceros TIC e intercambio de información. Aplicable desde el 17 de enero de 2025. Su exigencia supera a la de NIS 2 en el ámbito TIC, y el principio lex specialis le otorga prevalencia para las entidades financieras. ## Por qué existe DORA y a quién obliga Antes de DORA, la resiliencia operativa digital de las entidades financieras en la UE era un mosaico. Los bancos respondían a un conjunto de expectativas de supervisión, las aseguradoras a otro, y las normas sobre incidentes de TIC, externalización y pruebas variaban según el sector y según el Estado miembro. DORA sustituye esa fragmentación por un único reglamento que se aplica directamente en toda la Unión, sin necesidad de transposición nacional. Su ámbito es deliberadamente amplio: bancos, aseguradoras, empresas de servicios de inversión, entidades de pago y de dinero electrónico, proveedores de servicios de criptoactivos, centros de negociación y muchos más, además de los proveedores terceros críticos de servicios de TIC de los que dependen esas entidades. Ese último punto es lo que diferencia a DORA de una norma financiera habitual. No solo regula a las empresas supervisadas; alcanza su cadena de suministro. Los proveedores de nube, los operadores de centros de datos y los proveedores de software que se consideren críticos para el sistema financiero pueden quedar bajo supervisión directa a nivel de la UE. Para un profesional, la consecuencia práctica es que la resiliencia ya no es algo que se pueda externalizar por completo y olvidar. Usted sigue siendo responsable del riesgo de TIC que asumen sus proveedores, y tiene que demostrarlo. ## Los cinco pilares en la práctica DORA se asienta sobre cinco pilares, y cada uno se traduce en trabajo concreto de programa más que en papeleo: - Gestión del riesgo de TIC. Un marco de gobernanza propiedad del órgano de dirección, que abarca la identificación, la protección, la detección, la respuesta y la recuperación de los activos de TIC. Es la columna vertebral de la que penden los otros cuatro pilares. - Gestión y notificación de incidentes. Clasificar los incidentes relacionados con las TIC por gravedad y notificar los importantes a la autoridad competente dentro de un plazo definido. El énfasis está en una taxonomía armonizada para que los supervisores de toda la UE vean datos comparables. - Pruebas de resiliencia operativa digital. Un programa de pruebas periódico que va desde las evaluaciones de vulnerabilidades hasta las pruebas de penetración basadas en amenazas (TLPT) para las entidades más significativas, modeladas sobre el comportamiento real de los adversarios. - Gestión del riesgo de terceros proveedores de TIC. Salvaguardas contractuales, registros de información sobre todos los acuerdos de TIC, estrategias de salida y el régimen de supervisión de los proveedores terceros críticos. - Intercambio de información. Intercambio voluntario de inteligencia sobre ciberamenazas entre entidades financieras, fomentado en lugar de impuesto, para reforzar la defensa colectiva. > **Resiliencia, no solo seguridad** DORA trata de que el sistema financiero siga operativo bajo tensión, no solo de mantener fuera a los atacantes. Por eso se apoya tanto en las pruebas, la recuperación y la continuidad con terceros. Da por supuesto que las cosas se romperán y pregunta si usted puede seguir prestando las funciones críticas cuando eso ocurra, que es donde se solapa con la continuidad de negocio y con ISO 22301. ## DORA frente a NIS 2 La pregunta que más hacen los profesionales es cómo se relaciona DORA con NIS 2, ya que ambos son instrumentos de la UE que tocan la ciberseguridad y ambos alcanzan más o menos el mismo nivel de madurez. La respuesta corta es lex specialis: cuando DORA y NIS 2 se aplicarían ambos a una entidad financiera en el ángulo de TIC, DORA prevalece por ser la norma más específica. NIS 2 fija una base amplia de ciberseguridad en muchos sectores; DORA profundiza en la resiliencia de TIC del sector financiero y añade el régimen de supervisión de terceros que NIS 2 no tiene. **DORA comparado con NIS 2** | Dimensión | DORA | NIS 2 | | --- | --- | --- | | Tipo de instrumento | Reglamento, directamente aplicable | Directiva, transpuesta por los Estados miembros | | Ámbito principal | Entidades financieras y sus proveedores de TIC críticos | Entidades esenciales e importantes en muchos sectores | | Enfoque | Resiliencia operativa digital del sistema financiero | Gestión y notificación general del riesgo de ciberseguridad | | Supervisión de terceros | Supervisión directa de la UE de los proveedores de TIC críticos | Se espera seguridad de la cadena de suministro, sin régimen de supervisión directa | | Prelación para las finanzas | Prevalece como lex specialis en el ángulo de TIC | Cede ante DORA cuando ambos se aplicarían | En el día a día, un banco no puede elegir uno. Mapea sus obligaciones y comprueba que, para el riesgo de TIC, la notificación de incidentes y las pruebas de resiliencia, DORA es el texto que rige, mientras que NIS 2 todavía puede importar para partes del grupo que quedan fuera del ámbito financiero de DORA. La forma limpia de gestionar esto es un único marco de control, a menudo anclado en ISO 27001 e ISO 22301, que satisfaga ambos regímenes y permita evidenciar el cumplimiento una sola vez. --- ## Directiva NIS 1 (NIS 1) **URL:** https://cyberacademy.net/es/resources/encyclopedia/nis-1 **Last reviewed:** 2026-06-24 NIS 1 (Directiva 2016/1148) fue la primera directiva europea de ciberseguridad con alcance transectorial, aplicable a los operadores de servicios esenciales y a los proveedores de servicios digitales. Fue sustituida por NIS 2 en octubre de 2024, debido a que su ámbito de aplicación era demasiado estrecho, la aplicación desigual y la notificación de incidentes carecía de efecto real. Se menciona aquí principalmente para que sepan qué era realmente el «régimen anterior» que sus colegas aún recuerdan a medias. ## Qué pretendía lograr NIS 1 La Directiva NIS 1 fue el primer intento de la Unión Europea de establecer un nivel mínimo común de ciberseguridad para los sectores que mantienen en funcionamiento a un país. Antes de ella, los Estados miembros abordaban la seguridad de las infraestructuras críticas según sus propios términos, sin una base compartida ni una forma coordinada de gestionar los incidentes transfronterizos. NIS 1 cambió eso al pedir a cada Estado miembro que identificara a los operadores cuya interrupción tendría un grave efecto en cadena, los sujetara a obligaciones de seguridad y de notificación de incidentes, y constituyera la maquinaria nacional encargada de supervisarlos. En Francia esa maquinaria era ANSSI, y los operadores que designó ya conocían el régimen más pesado de OIV, anterior a la directiva. Por ser una directiva y no un reglamento, NIS 1 no se aplicaba directamente. Cada Estado miembro tenía que transponerla a su derecho nacional, de donde procede gran parte de la disparidad. Dos Estados podían leer el mismo texto y terminar con listas diferentes de entidades reguladas, umbrales de notificación distintos y apetitos muy diferentes por la aplicación. Ese mosaico es la principal razón por la que el régimen acabó siendo reconstruido. ## Dos categorías: servicios esenciales y proveedores de servicios digitales NIS 1 dividió el mundo regulado en dos grupos, y la distinción importa porque las obligaciones y la supervisión no eran simétricas. **Categorías NIS 1** | Aspecto | Operadores de servicios esenciales | Proveedores de servicios digitales | | --- | --- | --- | | Quiénes eran | Energía, transporte, banca, infraestructuras de los mercados financieros, salud, agua potable, infraestructuras digitales | Mercados en línea, motores de búsqueda, servicios de computación en la nube | | Cómo quedaban incluidos | Identificados caso por caso por cada Estado miembro según criterios | Incluidos automáticamente en el ámbito, con un enfoque más ligero | | Supervisión | Proactiva: las autoridades podían auditar y exigir pruebas | Mayormente reactiva: actuación tras un incidente | | Expectativa de seguridad | Medidas técnicas y organizativas adecuadas y proporcionadas | Medidas similares, pero un régimen regulatorio más ligero | Los operadores de servicios esenciales eran el núcleo de la directiva. Los Estados miembros tenían que nombrarlos, y una vez nombrados asumían obligaciones reales de gestionar el riesgo y de notificar los incidentes significativos a la autoridad nacional o al CSIRT. Los proveedores de servicios digitales recibían un trato más ligero bajo la teoría de que ya operaban a través de las fronteras y competían en resiliencia, de modo que un régimen armonizado pero más ligero evitaría fragmentar el mercado único. > **Por qué todavía se oye hablar de NIS 1** Si un colega habla de ser un «operador regulado» o de que ANSSI designó a su organización, normalmente está recordando la era de NIS 1. Las obligaciones no desaparecieron, fueron absorbidas y ampliadas por NIS 2, que entró en vigor en octubre de 2024. ## Por qué fue reemplazada El veredicto honesto sobre NIS 1 es que demostró el concepto pero quedó por debajo de lo prometido. Tres debilidades surgieron de forma repetida. El ámbito era demasiado estrecho, dejando sectores enteros y la mayoría de las organizaciones medianas fuera de cualquier obligación incluso cuando su fallo causaría daño. La aplicación era desigual, porque la transposición dejaba a cada Estado miembro decidir quién entraba en el ámbito y con cuánta firmeza presionar, de modo que una empresa podía estar regulada en un país e intacta justo al lado. Y la notificación de incidentes era en la práctica inofensiva, con umbrales y plazos que variaban tanto que la visibilidad transfronteriza que la directiva debía crear nunca se materializó realmente. NIS 2 fue la respuesta a los tres problemas. Amplió el ámbito a muchos más sectores y a un criterio basado en el tamaño, sustituyó la división OES/DSP por entidades esenciales e importantes, endureció la notificación de incidentes en etapas más claras, y respaldó las obligaciones con una verdadera responsabilidad de la dirección y sanciones. Para un profesional de hoy, NIS 1 es sobre todo contexto: explica la forma de las reglas bajo las que ahora vive y los reflejos que su organización construyó antes de la reconstrucción. --- ## Directiva ePrivacy (ePrivacy) **URL:** https://cyberacademy.net/es/resources/encyclopedia/eprivacy **Last reviewed:** 2026-06-24 La Directiva ePrivacy (2002/58/CE, modificada en 2009) es la «ley de cookies» que todo el mundo implementa a medias. Regula la confidencialidad de las comunicaciones electrónicas y las tecnologías de seguimiento en los dispositivos de los usuarios. Es anterior al GDPR y sigue en vigor; el Reglamento ePrivacy que debía sustituirla lleva bloqueado en negociación desde 2017. Las autoridades de control nacionales (CNIL, Garante, AEPD) la aplican en sus respectivos territorios. ## Qué regula realmente la Directiva ePrivacy La Directiva ePrivacy (2002/58/CE, modificada por la 2009/136/CE) es conocida sobre todo como la «ley de cookies», pero reducirla a las cookies hace perder la mayor parte de su peso. Su verdadero objeto es la confidencialidad de las comunicaciones electrónicas y la protección del equipo terminal del usuario. Establece que las comunicaciones y sus datos de tráfico asociados son confidenciales, que la interceptación y la vigilancia necesitan una base jurídica, y que almacenar o leer información en el dispositivo de una persona, ya sea una cookie, un píxel de seguimiento, una huella digital o un SDK, requiere por lo general consentimiento previo. La parte de consentimiento y seguimiento es la que la mayoría de los equipos implementa; la parte de confidencialidad es la que la mayoría de los equipos olvida que existe. Es una directiva, no un reglamento. Esa distinción es el origen de la mitad de la confusión en la práctica. Una directiva fija el objetivo y deja a cada Estado miembro transponerla a su derecho nacional, de modo que la redacción exacta, el umbral de consentimiento y el estilo de aplicación difieren de un país a otro. En Francia, las disposiciones pertinentes figuran en el Code des postes et des communications électroniques, y la CNIL publica sus propias directrices y recomendaciones sobre cookies y rastreadores. No existe un único texto a escala de la Unión que se pueda citar como se cita el GDPR. ## ePrivacy junto al GDPR Los dos instrumentos son complementarios, no intercambiables. La Directiva ePrivacy es lex specialis: allí donde establece una norma específica, esa norma prevalece sobre la disposición más general del GDPR. El ejemplo más claro son las cookies y el almacenamiento en el dispositivo. El GDPR regula cómo tratas los datos personales que recopilas; ePrivacy regula el acto de acceder a información en el dispositivo o de almacenarla en él en primer lugar, y se aplica incluso cuando no hay datos personales de por medio. Así, un rastreador que deposita un identificador puramente técnico sigue cayendo bajo ePrivacy, aunque argumentaras que no es un dato personal con arreglo al GDPR. El consentimiento bajo ePrivacy toma su definición del GDPR. Cuando ePrivacy exige consentimiento, este debe cumplir el estándar del GDPR: libre, específico, informado, inequívoco y tan fácil de retirar como de otorgar. Por eso las casillas premarcadas, los banners de «al continuar navegando, aceptas» y los muros de cookies que no ofrecen una opción real siguen suspendiendo la revisión de las autoridades de control. Los dos textos se leen conjuntamente. > **Más antigua que el GDPR, aún en vigor** ePrivacy es anterior al GDPR en bastante más de una década y sigue plenamente en vigor. El Reglamento ePrivacy que debía sustituirla y alinear el calendario con el del GDPR lleva atascado en negociación desde 2017. Hasta que se materialice, la directiva de 2002 tal como fue modificada en 2009, más la transposición de cada país, es la ley que debes cumplir. ## Qué hacen realmente los profesionales En el trabajo diario, el cumplimiento de ePrivacy gira sobre todo en torno a la capa de consentimiento y el inventario que la sustenta. El programa práctico es así: - Inventariar cada cookie, etiqueta, píxel, SDK y script que lee del dispositivo o escribe en él, y clasificar cada uno como estrictamente necesario o no. Solo los estrictamente necesarios están exentos de consentimiento. - Bloquear los rastreadores no esenciales hasta que el usuario haya dado su consentimiento, en lugar de dispararlos al cargar la página y preguntar después. Una plataforma de gestión del consentimiento suele imponer esto. - Hacer que rechazar sea tan fácil como aceptar, registrar el consentimiento y su alcance, y ofrecer una forma sencilla de retirarlo más adelante. - Tener presentes también las obligaciones de confidencialidad: el marketing directo por correo electrónico o SMS necesita por lo general un consentimiento previo (opt-in), con una excepción estrecha para los clientes existentes en productos similares. La aplicación es nacional. Como no hay un regulador central de la UE para ePrivacy, cada autoridad de protección de datos vigila su propio territorio. La CNIL en Francia, el Garante en Italia y la AEPD en España emiten cada una directrices, realizan auditorías e imponen sanciones con arreglo a sus transposiciones nacionales. Eso significa que un sitio paneuropeo no puede dar por sentado que un solo banner satisface a todos; el enfoque prudente es cumplir la interpretación más estricta entre los mercados a los que sirves y documentar las decisiones que tomaste. --- ## Disaster Recovery (DR) **URL:** https://cyberacademy.net/es/resources/encyclopedia/disaster-recovery **Last reviewed:** 2026-06-24 Disaster recovery es el subconjunto de la gestión de continuidad de negocio (BCM) centrado en TI: restaurar infraestructura, aplicaciones y datos tras una interrupción. El RPO, el RTO y los runbooks residen aquí. Un plan de DR que nunca se ha probado de extremo a extremo es pura ficción. ISO 24762 lo cubría anteriormente; la práctica actual remite a ISO 22301 más los runbooks operativos. ## Dónde se sitúa la recuperación ante desastres dentro de la continuidad La recuperación ante desastres es la sala de máquinas técnica de la continuidad de negocio. La gestión de la continuidad de negocio se pregunta cómo la organización sigue prestando sus actividades críticas durante una interrupción, abarcando personas, instalaciones, proveedores y procesos. La recuperación ante desastres responde a una pregunta más estrecha: cómo recuperamos las TI. Servidores, redes, aplicaciones, bases de datos y los propios datos. Cuando un centro de datos se inunda, una cepa de ransomware cifra la producción o una región de nube se apaga, el plan de recuperación es el documento y la memoria muscular que vuelve a poner los sistemas en marcha en un orden conocido, hasta un punto en el tiempo conocido. Esa distinción importa porque ambas a menudo se confunden. Un plan de continuidad puede describir soluciones manuales que mantienen vivo un servicio mientras las TI están caídas. Un plan de recuperación no tiene ese lujo. Se juzga únicamente por si los sistemas vuelven, con qué rapidez y cuántos datos se perdieron. Tratar la recuperación como un subconjunto de la continuidad en lugar de como un sinónimo mantiene el alcance honesto e impide que los equipos asuman que un servidor recuperado significa un servicio de negocio recuperado. ## RTO, RPO y el runbook Dos cifras gobiernan cada decisión de recuperación. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo tolerable que un sistema puede estar caído antes de que el impacto se vuelva inaceptable. El objetivo de punto de recuperación (RPO) es la cantidad máxima tolerable de pérdida de datos, expresada como una ventana de tiempo, lo que en la práctica dicta con qué frecuencia replica o realiza copias de seguridad. Un RTO de cuatro horas con un RPO de quince minutos es una arquitectura muy diferente, y un presupuesto muy diferente, de un RTO para el siguiente día hábil con una copia de seguridad diaria. Estos objetivos deben provenir de un análisis de impacto en el negocio, no del nivel de comodidad del equipo de infraestructura. - El RTO determina la arquitectura de recuperación: redundancia en caliente y replicación para objetivos estrictos, restauración desde copia de seguridad para los más flexibles. - El RPO determina la estrategia de protección de datos: replicación síncrona, instantáneas o copias de seguridad periódicas. - El runbook convierte esos objetivos en un procedimiento de recuperación probado, paso a paso, que alguien bajo presión puede seguir realmente. > **Un plan no probado es una ficción** Un plan de recuperación que nunca se ha ejercitado de extremo a extremo es una hipótesis, no una capacidad. Las copias de seguridad que nunca se han restaurado, la conmutación por error que nunca se ha activado y los runbooks que nadie ha ensayado fallan habitualmente en el peor momento. Programe pruebas de recuperación, realice simulaciones de mesa del flujo de decisión y documente las brechas que cada ejercicio revela. ## Normas, amenazas y práctica actual El panorama normativo ha cambiado. ISO/IEC 24762 ofreció en su día orientación específica sobre los servicios de recuperación ante desastres de las TIC, pero se ha retirado, y la práctica actual remite de nuevo a ISO 22301 para el sistema de gestión de la continuidad de negocio, mientras que ISO/IEC 27031 cubre la preparación de las TIC para la continuidad de negocio. En ese modelo, la recuperación no es una disciplina independiente; es la capa operativa que materializa la estrategia de continuidad, gobernada por el mismo sistema de gestión y el mismo apetito de riesgo. Los sectores regulados añaden su propia presión: el régimen de resiliencia del sector financiero de la UE, por ejemplo, espera que las firmas demuestren que la recuperación y la continuidad de las funciones críticas se prueban, no solo se documentan. La recuperación moderna también está moldeada por las amenazas que debe absorber. El ransomware en particular ha reescrito el guion, porque si sus copias de seguridad son accesibles y escribibles desde el entorno de producción, un atacante también las cifra. Los profesionales ahora prefieren copias de seguridad inmutables y aisladas, entornos de recuperación segmentados y reconstrucciones en sala limpia para que la restauración no vuelva a infectar sin más. La nube y la infraestructura como código han hecho que algunas recuperaciones sean más rápidas de automatizar, pero introducen sus propios puntos únicos de fallo en las capas de región, cuenta e identidad. La disciplina es la misma de siempre: conozca sus objetivos, proteja sus datos para que sobrevivan al desastre, escriba un runbook que alguien pueda seguir y demuestre que funciona antes de necesitarlo. --- ## EBIOS Risk Manager (EBIOS RM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ebios-rm **Last reviewed:** 2026-06-24 EBIOS Risk Manager es el método de ciberriesgo de ANSSI, centrado en escenarios de ataque estratégicos. Mapea los procesos de negocio frente a los objetivos del atacante y deriva a partir de ahí los controles técnicos. Es el estándar en el sector público francés y en los operadores de importancia vital. Resulta especialmente útil para mostrar al consejo de administración POR QUÉ importa un escenario concreto; es menos habitual en auditorías multinacionales del sector privado. ## Lo que EBIOS Risk Manager hace realmente EBIOS Risk Manager es el método de evaluación de riesgos cibernéticos mantenido por ANSSI, la agencia nacional francesa de ciberseguridad. Su rasgo definitorio es partir del atacante, no de una lista de activos. En lugar de catalogar cada servidor y preguntarse qué podría salir mal con cada uno, el método se pregunta quién querría dañar a la organización, qué intentaría conseguir y qué misiones de negocio atacaría para lograrlo. Los controles técnicos llegan al final, derivados de los escenarios, en lugar de ser el punto de partida. Esta lógica inversa es lo que hace que EBIOS RM resulte útil ante un consejo de administración. Un registro de riesgos tradicional, construido de abajo hacia arriba, produce cientos de líneas que significan poco para los directivos. EBIOS RM produce un puñado de escenarios estratégicos, como un actor patrocinado por un Estado interrumpiendo un servicio crítico, o un competidor exfiltrando datos de diseño, cada uno vinculado a una misión de negocio concreta. Ese encuadre responde a la pregunta que los directivos plantean realmente: por qué nos importa esta amenaza concreta, y cuánto nos costaría si llegara a ocurrir. ## Los cinco talleres EBIOS RM se estructura como una secuencia de talleres, cada uno apoyándose en el anterior. El método es deliberadamente colaborativo: reúne en la misma sala a los responsables de negocio, los especialistas en riesgos y los equipos de seguridad, en lugar de dejar el análisis a un único analista. 1. Alcance y base de seguridad. Definir el perímetro de negocio y técnico, identificar las misiones y los eventos temidos, y evaluar la base de seguridad existente frente a lo que se espera. 1. Orígenes del riesgo. Identificar los orígenes del riesgo y sus objetivos perseguidos, el emparejamiento entre quién podría atacar y qué busca, y luego priorizar los más relevantes. 1. Escenarios estratégicos. Cartografiar el ecosistema de socios, proveedores y partes interesadas, evaluar cómo un atacante podría alcanzar a la organización a través de ellos, y construir rutas de ataque de alto nivel. 1. Escenarios operativos. Traducir los escenarios estratégicos en secuencias de ataque técnicas concretas, describiendo cómo se movería realmente un adversario a través de los sistemas. 1. Tratamiento del riesgo. Decidir las medidas de seguridad, elaborar el plan de tratamiento y documentar el riesgo residual que la dirección acepta formalmente. > **Orientada a escenarios, no a activos** EBIOS RM deriva los controles de escenarios de ataque realistas en lugar de un inventario exhaustivo de activos. Esto mantiene el análisis centrado en las amenazas que realmente importan al negocio, y ofrece a la dirección una base defendible para aceptar o tratar el riesgo residual. ## Dónde encaja y dónde no EBIOS RM es el método de referencia en el sector público francés y entre los operadores de importancia vital, donde las expectativas regulatorias remiten a las directrices de ANSSI. También se enseña y utiliza ampliamente en las organizaciones francófonas. Fuera de ese contexto, en las auditorías multinacionales del sector privado, es mucho más probable que encuentre ISO 27005, que es la norma internacional de gestión de riesgos de seguridad de la información y, por diseño, es independiente del método. Ambos son complementarios más que rivales. ISO 27005 describe un proceso genérico de gestión de riesgos alineado con ISO 27001 e ISO 31000, pero no prescribe una técnica única. EBIOS RM es una forma concreta y reconocida de llevar a cabo ese proceso, y ANSSI la posiciona como compatible con el enfoque ISO. Un equipo puede realizar talleres EBIOS RM y aun así presentar los resultados en términos de ISO 27005. **EBIOS Risk Manager comparado con ISO 27005** | Aspecto | EBIOS Risk Manager | ISO 27005 | | --- | --- | --- | | Origen | ANSSI (Francia) | Norma internacional ISO/IEC | | Naturaleza | Método prescriptivo con talleres definidos | Directrices de gestión de riesgos independientes del método | | Punto de partida | Objetivos del atacante y misiones de negocio | Activos, amenazas y vulnerabilidades | | Contexto típico | Sector público francés, operadores de importancia vital | Auditorías internacionales de SGSI del sector privado | En la práctica, conocer EBIOS RM denota soltura con el ecosistema de ANSSI, y conocer ISO 27005 denota soltura con el mundo de las normas internacionales. Los profesionales del riesgo que trabajan en los mercados europeos y franceses se benefician de dominar ambos, porque el método al que se recurre depende de quién vaya a leer el informe. --- ## EU AI Act (AI Act) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ai-act **Last reviewed:** 2026-06-24 El EU AI Act es la primera regulación integral de IA del mundo. Cuatro niveles de riesgo: inaceptable (prohibido), alto (obligaciones estrictas y evaluación de conformidad), limitado (transparencia), mínimo. Se aplica de forma progresiva hasta agosto de 2027. Combínalo con ISO 42001 si se busca una respuesta basada en sistema de gestión y no en una lista de verificación. Las normas sobre modelos GPAI se superponen a este marco. ## Una ley basada en el riesgo, no una prohibición tecnológica El EU AI Act regula la inteligencia artificial por lo que hace un sistema y a quién puede afectar, no por el algoritmo que lo sustenta. Una misma técnica de aprendizaje automático puede estar no regulada en un contexto y estrictamente controlada en otro. Esa es la idea central de los cuatro niveles de riesgo: las prácticas inaceptables están prohibidas de forma directa, los sistemas de alto riesgo cargan con las obligaciones más pesadas, los sistemas de riesgo limitado deben transparencia a las personas que interactúan con ellos, y los sistemas de riesgo mínimo quedan en gran medida intactos. La mayor parte de la IA de uso cotidiano se sitúa en esa banda mínima, razón por la cual el Act se entiende mejor como una regulación específica de los usos con consecuencias que como un régimen de licencia general para toda la IA. El Act es un reglamento, por lo que se aplica directamente en cada Estado miembro sin que cada país tenga que transponerlo a su derecho nacional. Su alcance también es extraterritorial en espíritu: los proveedores e implementadores fuera de la UE entran en el ámbito de aplicación cuando su sistema de IA se introduce en el mercado de la UE o sus resultados se utilizan en la Unión. Los profesionales deberían mapear sus sistemas frente a los niveles desde el principio, porque la clasificación determina todo lo que sigue, desde la documentación hasta la evaluación de la conformidad. ## Dónde muerden realmente las obligaciones Casi todo el peso operativo recae sobre los sistemas de alto riesgo. Suele tratarse de IA utilizada en productos regulados o en ámbitos sensibles como las infraestructuras críticas, el empleo, el acceso a servicios esenciales, la aplicación de la ley y la administración de justicia. Para estos, el Act espera un conjunto de disciplinas operativas en lugar de un formulario puntual: un sistema de gestión de riesgos mantenido a lo largo del ciclo de vida, gobernanza de los datos de entrenamiento y prueba, documentación técnica, registro, transparencia e instrucciones de uso, supervisión humana que permita a una persona intervenir de forma significativa, y un nivel adecuado de exactitud, robustez y ciberseguridad. Antes de que un sistema de alto riesgo llegue al mercado debe superar una evaluación de la conformidad, y los proveedores realizan una vigilancia poscomercialización una vez que está en funcionamiento. > **Proveedor e implementador no son el mismo rol** El Act reparte las obligaciones entre el proveedor que desarrolla o introduce el sistema en el mercado y el implementador que lo utiliza bajo su propia autoridad. Un banco que despliega un modelo de scoring crediticio de un tercero asume deberes de implementador como la supervisión humana y el seguimiento, mientras que el proveedor asume los deberes de proveedor. Saber qué sombrero llevas decide qué obligaciones son tuyas. ## GPAI, transparencia y el calendario por fases Por encima de los niveles se sitúa un régimen aparte para los modelos de IA de uso general, los modelos fundacionales que impulsan muchas aplicaciones posteriores. Los proveedores de GPAI afrontan deberes de transparencia y documentación, con requisitos más estrictos para los modelos más capaces que se considera que conllevan riesgo sistémico. Esta capa se añadió precisamente porque un único modelo de uso general puede fluir hacia innumerables usos de alto riesgo y de riesgo limitado, de modo que regular solo la aplicación final dejaría un vacío. Las obligaciones de riesgo limitado son más ligeras pero reales. Se centran en la transparencia: las personas deberían saber cuándo están interactuando con un sistema de IA, y ciertos contenidos sintéticos o manipulados deberían marcarse como generados artificialmente. El Act entra en vigor y se aplica por fases, con las prohibiciones, las normas de GPAI y las obligaciones de alto riesgo activándose en momentos distintos hasta 2027, lo que da a las organizaciones un margen pero también una secuencia de plazos firmes que planificar. ## Cómo lo operacionalizan los profesionales En la práctica, el Act es una lista de obligaciones legales, no un método de gestión, así que los equipos lo combinan con un sistema capaz de sostener esas obligaciones en el día a día. ISO/IEC 42001 es la respuesta habitual: un sistema de gestión de IA te aporta las evaluaciones de riesgo, la gobernanza de datos, las rutinas de supervisión humana y de vigilancia poscomercialización que el Act espera, ejecutadas como un sistema repetible en lugar de improvisadas bajo la presión del plazo. El NIST AI Risk Management Framework se usa a menudo en paralelo como estructura voluntaria para identificar y tratar el riesgo de IA. Ninguno de estos hace que un sistema cumpla legalmente por sí solo. Hacen que el cumplimiento sea alcanzable y auditable, que es la diferencia entre demostrar la debida diligencia y confiar en que nadie pregunte. --- ## Ejercicio de mesa (tabletop exercise) **URL:** https://cyberacademy.net/es/resources/encyclopedia/tabletop **Last reviewed:** 2026-06-24 Un tabletop exercise es una simulación basada en discusión de un escenario disruptivo con el equipo de respuesta reunido en torno a una mesa. Económico, rápido, expone las brechas que ninguna revisión documental revelará. Práctica exigida por ISO 22301, NIS 2 y DORA, y la actividad de mayor ROI en un programa de BCM. Planifíquelos trimestralmente, no anualmente. ## Qué es realmente un ejercicio de mesa Un ejercicio de mesa reúne en una misma sala a las personas que tendrían que responder a una interrupción, las guía a través de un escenario realista y les pide que expliquen lo que harían, paso a paso. Nadie toca los sistemas de producción. Nadie conmuta nada a un sitio de recuperación. Todo el sentido reside en la conversación: quién decide, a quién se llama, qué dice el plan frente a lo que el equipo haría realmente, y dónde el documento queda en silencio justo en el momento en que se necesita una decisión. Está basado en el debate por diseño, y por eso resulta barato y rápido de ejecutar. Ese bajo coste es la razón por la que es la actividad de mayor rentabilidad de un programa de continuidad o de respuesta a incidentes. Un facilitador presenta una situación inicial y luego inyecta nueva información a medida que avanza el debate: la copia de seguridad también está cifrada, la prensa tiene la historia, el responsable de guardia está ilocalizable. El equipo razona en voz alta y las carencias afloran ante las personas capaces de corregirlas. Una revisión documental nunca produce eso. Leer un plan confirma que existe. Recorrer un escenario revela si alguien lo entiende, si la lista de contactos está actualizada y si dos equipos dan por hecho cada uno que es el otro quien declara el incidente. ## En qué se diferencia de otros tipos de ejercicio Los ejercicios de mesa se sitúan en un extremo de un espectro de rigor. Son deliberadamente el formato más ligero, lo que los hace adecuados para ejecutarse con frecuencia. Los ejercicios más pesados validan los mecanismos de los que un ejercicio de mesa solo habla, con un coste y una perturbación mucho mayores. **Comparación de tipos de ejercicio** | Tipo de ejercicio | Qué hace | Coste y perturbación | | --- | --- | --- | | Ejercicio de mesa | Recorrido de un escenario basado en el debate, alrededor de una mesa; saca a la luz las carencias de decisión y de plan | Bajo | | Repaso / simulacro | Ensayo paso a paso de un único procedimiento, como un árbol de llamadas o una restauración | Bajo a moderado | | Ejercicio funcional | Activación real de funciones de respuesta concretas sin afectar a la producción | Moderado a alto | | Prueba a gran escala / en condiciones reales | Conmutación o recuperación real en condiciones cercanas a un incidente verdadero | Alto | El error habitual es tratar el ejercicio de mesa como un sustituto de la prueba en condiciones reales. No lo es. Un ejercicio de mesa demuestra que las personas conocen el plan y saben tomar decisiones; solo una prueba funcional o a gran escala demuestra que las copias de seguridad se restauran realmente y que los objetivos de recuperación son alcanzables. Un programa maduro utiliza ambos: ejercicios de mesa frecuentes que alimentan las lecciones que hacen que valga la pena ejecutar las pruebas reales, escasas y costosas. > **Prográmelos cada trimestre, no cada año** Los planes se desfasan en cuanto una organización se reorganiza, cambia de proveedor o adopta un sistema nuevo. Un ejercicio de mesa ejecutado una vez al año prueba un plan que ya está obsoleto. Ejecutarlos cada trimestre mantiene honestas las listas de contactos, los derechos de decisión y las hipótesis de recuperación, y conserva al equipo de respuesta entrenado en lugar de oxidado. ## El lugar de los ejercicios de mesa en las normas y la regulación Realizar ejercicios no es opcional según los marcos que rigen la resiliencia. ISO 22301, la norma internacional para los sistemas de gestión de continuidad del negocio, exige que las disposiciones de continuidad se ejerciten y se prueben, y el ejercicio de mesa es la forma más común en que las organizaciones cumplen ese requisito entre pruebas reales. En la Unión Europea, la Directiva NIS 2 espera medidas de continuidad del negocio y de gestión de crisis por parte de los operadores de los sectores esenciales e importantes, y el Digital Operational Resilience Act establece expectativas de prueba explícitas para las entidades financieras, donde los ejercicios basados en escenarios forman parte del programa de pruebas de resiliencia. Lo que buscan los auditores y los reguladores no es solo que se haya realizado un ejercicio, sino que se haya documentado y se haya actuado en consecuencia. Un ejercicio de mesa que no produce ningún registro ni ninguna acción correctiva es puro teatro. El valor se materializa en el informe posterior a la acción: qué falló, quién es responsable de la corrección y cuándo se volverá a probar. Ese bucle, del escenario al hallazgo, luego a la corrección y al siguiente ejercicio, es lo que convierte un ejercicio de mesa de una casilla que marcar en el motor que mantiene actualizado un programa de continuidad. --- ## Endpoint Detection and Response (EDR) **URL:** https://cyberacademy.net/es/resources/encyclopedia/edr **Last reviewed:** 2026-06-24 EDR es la plataforma basada en agente que registra la actividad del endpoint, detecta comportamientos sospechosos y permite a los analistas aislar o remediar hosts comprometidos. XDR amplía la visibilidad a endpoints, red y nube; MDR es la capa de servicio gestionado. El endpoint sigue siendo el vector de entrada más habitual; EDR es hoy un requisito mínimo, no un diferenciador. ## Lo que el EDR hace realmente en el host Endpoint Detection and Response ejecuta un agente ligero en cada estación de trabajo, portátil y servidor que le importa. Ese agente registra de forma continua lo que hace el sistema operativo: los procesos que se inician, las líneas de comandos que ejecutan, los archivos que se escriben, las claves de registro que cambian, las conexiones de red que se abren y las sesiones de usuario que comienzan. Este flujo de telemetría es el corazón del EDR. Donde el antivirus tradicional hacía una sola pregunta, «¿se sabe que este archivo es malicioso?», el EDR plantea una más difícil, «¿es sospechosa esta secuencia de comportamientos?», lo que le permite detectar ataques sin archivos, técnicas de living-off-the-land y el abuso de herramientas legítimas que nunca dejan una muestra de malware reconocible. La mitad de «respuesta» es lo que separa al EDR de un sensor pasivo. Cuando un host se ve comprometido, un analista puede actuar desde la consola: aislar la máquina de la red manteniendo viva la conexión del agente, terminar un proceso malicioso, poner un archivo en cuarentena, recopilar artefactos forenses o revertir cambios. Esa capacidad de contener un único endpoint sin tocarlo físicamente, en plena gestión de un incidente activo, es la que más utilizan los profesionales. La telemetría también alimenta la investigación, de modo que los respondedores pueden reconstruir toda la cadena de lo que hizo un atacante en lugar de limitarse a bloquear la primera etapa. ## EDR, XDR y MDR: conocer la diferencia Estos tres acrónimos se venden uno al lado del otro y es fácil confundirlos. No son tanto productos que compiten entre sí como ámbitos y modelos de entrega distintos construidos en torno a la misma idea central. **EDR vs XDR vs MDR** | Término | Ámbito | Qué es | | --- | --- | --- | | EDR | Solo endpoints | La plataforma basada en agentes que registra, detecta y responde en los hosts. Usted la opera por su cuenta. | | XDR | Endpoint, red, nube, identidad, correo | Amplía y correlaciona la detección a través de varias capas, no solo el endpoint, para ver los ataques que abarcan varios dominios. | | MDR | Lo que cubra el proveedor | Un servicio gestionado: un equipo externo ejecuta la detección y la respuesta en su nombre, a menudo apoyándose en EDR o XDR. | La lectura práctica es sencilla. El EDR es la tecnología en el host. El XDR es la misma filosofía de detección ampliada para ingerir señales más allá del endpoint y correlacionarlas. El MDR es una decisión de externalización: usted compra los analistas y la cobertura ininterrumpida, no solo la herramienta. Un equipo pequeño sin un SOC 24/7 con frecuencia combina el EDR con un proveedor de MDR para que las alertas se clasifiquen a las tres de la madrugada. ## Dónde encaja el EDR en sus operaciones y en su SGSI El EDR rara vez funciona solo. Sus detecciones y su telemetría en bruto se reenvían habitualmente a un SIEM para correlacionarlas con los registros de cortafuegos, proveedores de identidad y aplicaciones, y las alertas resultantes las trabaja un SOC. En ese flujo, el EDR es el sensor de alta fidelidad más cercano al lugar donde comienzan la mayoría de las intrusiones, ya que el endpoint sigue siendo el punto de entrada más común mediante phishing, credenciales robadas y software vulnerable. Desde el punto de vista del gobierno, el EDR es lo que hace que varios objetivos de control sean reales en lugar de aspiracionales. Bajo un SGSI ISO/IEC 27001 respalda los controles relativos a la protección frente al malware, el registro, la supervisión y la parte técnica de la gestión de incidentes, y produce las evidencias que un auditor espera ver. También sustenta la capacidad de detección y respuesta que marcos como el modelo de funciones de ciberseguridad del NIST y normativas como NIS2 y DORA dan por hecho que una organización mantiene. La shortDefinition lo dice con claridad: el EDR es ahora un requisito básico, no un factor de diferenciación. > **Una herramienta no es una capacidad** Desplegar el EDR es la parte fácil. El valor llega con la cobertura de cada activo, las detecciones ajustadas y las personas que clasifican y responden. Un agente instalado en la mitad de la flota, que genera alertas que nadie lee, ofrece garantía sobre el papel y ninguna en la práctica. --- ## Evaluación de Impacto sobre la Protección de Datos (DPIA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/dpia **Last reviewed:** 2026-06-24 Una DPIA es el análisis estructurado que el GDPR exige antes de un tratamiento de alto riesgo. Documenta la naturaleza, el alcance, el contexto y las finalidades; evalúa la necesidad y la proporcionalidad; identifica las medidas de mitigación. La CNIL ofrece una herramienta PIA gratuita: úsela. Omitir una DPIA cuando era obligatoria es una de las formas más directas de atraer una visita del regulador. ## Cuándo se requiere una EIPD, y cuándo no Una Evaluación de Impacto relativa a la Protección de Datos no es un trámite que se produce para cada proyecto. El RGPD la vincula a un único desencadenante: un tratamiento que probablemente entrañe un alto riesgo para los derechos y libertades de las personas. El texto menciona algunas situaciones en las que la evaluación es obligatoria, como la elaboración sistemática y exhaustiva de perfiles que produzca efectos jurídicos o efectos significativos similares, el tratamiento a gran escala de datos de categorías especiales y la observación sistemática a gran escala de una zona de acceso público. Las autoridades de control nacionales publican después sus propias listas de las operaciones que siempre requieren una EIPD, y listas de operaciones que no la requieren. En la práctica se comienza con un cribado. Contraste con el tratamiento una breve lista de criterios de riesgo, del tipo publicado por el Comité Europeo de Protección de Datos, y cuente cuántos se aplican. Combinaciones como la evaluación o puntuación junto con la toma de decisiones automatizada, o los datos sensibles junto con el tratamiento de datos a gran escala, le hacen superar el umbral. Cuando la respuesta es incierta, la postura defendible consiste en documentar por qué concluyó que no era necesaria una EIPD completa, y no en eludir la cuestión en silencio. > **El error más barato que conviene evitar** No llevar a cabo una EIPD cuando era necesaria, llevarla a cabo de forma incorrecta, o no consultar a la autoridad de control cuando el riesgo residual sigue siendo alto, son todos ellos incumplimientos directamente nombrados. Una EIPD ausente es una de las lagunas más fáciles de detectar para un regulador durante una inspección. ## Qué contiene la evaluación El RGPD fija un contenido mínimo. Una EIPD debe contener una descripción sistemática de las operaciones de tratamiento y de los fines, una evaluación de la necesidad y la proporcionalidad del tratamiento en relación con esos fines, una evaluación de los riesgos para los derechos y libertades de los interesados, y las medidas previstas para afrontar esos riesgos, incluidas las garantías y las medidas de seguridad. La CNIL ofrece de forma gratuita una herramienta de software PIA que le guía exactamente a través de esta estructura, y no hay razón para reconstruirla desde cero. La necesidad y la proporcionalidad son donde la mayoría de las evaluaciones flaquean. Se trata de una prueba jurídica, no de seguridad: ¿es cada campo de datos realmente necesario para el fin declarado, está justificado el plazo de conservación, existe una base jurídica, se garantizan los derechos de los interesados? El análisis de riesgos es la parte de carácter más cercano a la seguridad, y toma prestado directamente de la práctica de gestión de riesgos. Aquí es donde ISO 27005 y EBIOS Risk Manager le proporcionan el vocabulario de las amenazas, los eventos temidos, la probabilidad y la gravedad. Una EIPD evalúa el riesgo para las personas cuyos datos se tratan, no el riesgo para la organización, que es la distinción que hace tropezar a la gente. ## Quién la realiza, y cómo se mantiene viva El responsable del tratamiento es el encargado de llevar a cabo la EIPD. Cuando se designa un Delegado de Protección de Datos, el responsable del tratamiento debe recabar su asesoramiento, y el DPO normalmente revisa la evaluación y supervisa su ejecución. También debe recabar la opinión de los interesados o de sus representantes cuando proceda. Los encargados del tratamiento tienen el deber de asistir. Si, tras la mitigación, el riesgo residual sigue siendo alto y no puede reducirlo, el RGPD exige la consulta previa a la autoridad de control antes de que comience el tratamiento. Una EIPD es un documento vivo. El responsable del tratamiento debe revisarla cuando se produzca un cambio en el riesgo que representa el tratamiento, por ejemplo un nuevo flujo de datos, una nueva tecnología, un nuevo fin o un nuevo subencargado. Trátela como algo continuo: un ritmo útil consiste en reexaminar las evaluaciones según un ciclo definido y siempre que el diseño cambie, en lugar de archivarlas una vez y olvidarse de ellas. **La EIPD comparada con una evaluación de riesgos general** | Dimensión | EIPD | Evaluación de riesgos de seguridad general | | --- | --- | --- | | Desencadenante | Tratamiento de datos personales de alto riesgo | Cualquier activo, sistema o proceso dentro del alcance | | Objeto del riesgo | Derechos y libertades de las personas | La organización y sus activos | | Estatuto jurídico | Obligatoria conforme al RGPD cuando se desencadena | Impulsada por una política o normas como ISO 27001 | | Método típico | Herramienta PIA de la CNIL, criterios del EDPB, prueba de necesidad | ISO 27005, EBIOS Risk Manager | | Resultado | Medidas de mitigación más una posible consulta previa | Plan de tratamiento y aceptación del riesgo residual | --- ## Gestión de Información y Eventos de Seguridad (SIEM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/siem **Last reviewed:** 2026-06-24 Un SIEM agrega logs, normaliza eventos y ejecuta reglas de detección sobre toda la plataforma. Es la capa de visibilidad de la que depende el SOC. Los principales fabricantes de SIEM (Splunk, Sentinel, Elastic, Sumo) integran cada vez más capacidades de SOAR y UEBA. El trabajo duro no es adquirir el SIEM; es la ingeniería de datos y el pipeline de detección como código que viene después. ## Lo que un SIEM hace en realidad Un SIEM se sitúa en el centro de las operaciones de seguridad como motor de recopilación y correlación. Ingiere registros y eventos de todo el parque: cortafuegos, endpoints, proveedores de identidad, plataformas en la nube, servidores, aplicaciones y dispositivos de red. A continuación normaliza esos eventos en un esquema común, de modo que un fallo de autenticación de Windows, un inicio de sesión por VPN y una llamada a una API en la nube puedan analizarse en conjunto, y ejecuta reglas de detección sobre ese flujo unificado para generar alertas. La cuestión es la visibilidad. Sin un SIEM, las señales de seguridad quedan atrapadas en decenas de consolas que nadie correlaciona, y un ataque que afecta a cinco sistemas parece cinco eventos sin relación. Dos funciones hacen de un SIEM mucho más que una herramienta de búsqueda en registros. La primera es la correlación: reglas que solo se activan cuando ocurre una secuencia, por ejemplo un intento de fuerza bruta seguido de un inicio de sesión correcto y después una escalada de privilegios, algo que ninguna fuente por sí sola señalaría. La segunda es la retención y la búsqueda, que convierten al SIEM en el sistema de referencia para las investigaciones y en el lugar al que acude un analista para reconstruir lo sucedido. Como señala la shortDefinition, las plataformas modernas como Splunk, Microsoft Sentinel, Elastic y Sumo Logic incorporan cada vez más SOAR para la respuesta automatizada y UEBA para el análisis del comportamiento, de modo que las fronteras entre estas categorías se difuminan. ## SIEM, SOC, SOAR y EDR: quién hace qué Estos términos suelen ir juntos y es fácil confundirlos, pero describen cosas distintas: una herramienta, un equipo, una capa de automatización y un sensor. **Cómo encajan las piezas** | Término | Qué es | Relación con el SIEM | | --- | --- | --- | | SIEM | La plataforma de agregación, normalización y detección | La propia capa de visibilidad. | | SOC | El equipo y el proceso que supervisan y responden | Consume las alertas del SIEM; el SIEM es su consola principal. | | SOAR | Orquestación y playbooks de respuesta automatizada | Actúa sobre las alertas del SIEM para enriquecer, clasificar y contener. | | EDR | Sensor de endpoint con telemetría profunda del host | Una fuente de alta fidelidad que alimenta el SIEM. | La lectura práctica: el SIEM es la tecnología que lo ve todo, el SOC es el conjunto de personas que trabajan las alertas, SOAR es la automatización que reduce su trabajo manual, y EDR es una de las fuentes de datos más ricas que llegan. Un SIEM sin un SOC detrás genera alertas que nadie lee. Un SOC sin un SIEM está ciego. Se compran por separado, pero solo aportan valor juntos. ## Por qué el SIEM es la parte difícil Comprar un SIEM es un ejercicio de adquisición. Hacerlo útil es ingeniería de datos. El trabajo que realmente determina el éxito consiste en conectar las fuentes de registro adecuadas con cobertura completa, analizar correctamente cada fuente para que los campos aterricen en el lugar correcto, y afinar el contenido de detección para que los analistas obtengan verdaderos positivos en lugar de un aluvión de ruido que los entrena a ignorar las alertas. Por eso los equipos maduros tratan las detecciones como código: las reglas viven en un control de versiones, se prueban, se revisan por pares y se despliegan mediante una canalización, exactamente como el software de aplicaciones. La shortDefinition es tajante al respecto. El trabajo difícil no es comprar el SIEM; es la canalización de detección como código que viene después. Desde el punto de vista del gobierno, el SIEM es lo que impide que varios objetivos de control sigan siendo aspiracionales. Bajo un SGSI de ISO/IEC 27001 sustenta los controles de registro, supervisión y la vertiente de detección de la gestión de incidentes, y produce las evidencias que un auditor espera ver de que los eventos se capturan y revisan realmente. También operativiza la capacidad de detección y respuesta que presupone el NIST Cybersecurity Framework, y que regulaciones como NIS2 y DORA esperan que las organizaciones mantengan y puedan demostrar durante un incidente. > **El coste está en la ingesta** La mayoría de las plataformas SIEM cobran por volumen de datos, de modo que lo que decides recopilar es tanto una decisión presupuestaria como de seguridad. Los equipos que lo envían todo sin una estrategia de datos obtienen una factura elevada y búsquedas lentas. Decidir qué merece ser ingerido, qué resumir y qué descartar forma parte de operar bien un SIEM. --- ## Gestión de identidades y accesos (IAM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iam **Last reviewed:** 2026-06-24 IAM es la disciplina que gestiona quién puede acceder a qué, cuándo, cómo y bajo qué condiciones. Aprovisionamiento, autenticación, autorización, desaprovisionamiento. La identidad es el nuevo perímetro. Toda arquitectura Zero Trust es, en esencia, un problema de IAM exigente disfrazado de problema de red. ## Qué cubre realmente la IAM La Identity and Access Management es la disciplina operativa que decide quién puede acceder a qué, cuándo, cómo y bajo qué condiciones. En la práctica se construye a partir de un pequeño conjunto de funciones repetibles: aprovisionar una identidad cuando llega una persona o un servicio, autenticar esa identidad en el momento del acceso, autorizar las acciones y los recursos específicos permitidos, y desaprovisionar la identidad cuando termina el rol o la relación. La parte difícil rara vez es una única pantalla de inicio de sesión. Consiste en mantener honesto a lo largo del tiempo el vínculo entre una persona real, sus identidades digitales y sus permisos acumulados, a través de decenas de sistemas que tienen cada uno su propia idea de qué es una cuenta. Un modelo mental útil es el ciclo de vida de la identidad. Quienes se incorporan reciben cuentas y un acceso de base. Quienes cambian de puesto pasan de un equipo a otro y deberían perder sus permisos antiguos a medida que adquieren los nuevos. Quienes se van deben quedar desconectados de forma limpia. La mayoría de los incidentes de acceso se remontan a un fallo en este ciclo de vida: cuentas huérfanas que nunca se deshabilitaron, o privilegios que se acumularon porque el acceso se concedió pero nunca se revisó. La IAM es el sistema que hace que el proceso de incorporación, cambio y baja sea fiable en lugar de una improvisación manual. ## La identidad como perímetro La IAM importa más ahora porque el límite de red dejó de ser un control significativo. Los usuarios se conectan desde cualquier lugar, las cargas de trabajo se ejecutan en distintos proveedores de nube, y las identidades de máquina (cuentas de servicio, claves de API, tokens de carga de trabajo) suelen superar en número a las humanas. Cuando no hay un dentro y un fuera que defender, la identidad se convierte en la línea que decide el acceso. Esta es la idea central detrás del Zero Trust: nunca confiar por defecto, verificar cada solicitud frente a la identidad, la postura del dispositivo y el contexto. Una arquitectura Zero Trust es, en el fondo, un exigente problema de IAM disfrazado de problema de red. La IAM es también donde se conectan varios controles adyacentes. La autenticación multifactor refuerza el paso de autenticación. La gestión de accesos privilegiados protege el reducido número de identidades capaces de causar el mayor daño. El principio de mínimo privilegio es la política que la IAM aplica: conceder solo el acceso que un rol realmente necesita, y nada más. Trátelos como capas de un mismo problema y no como proyectos separados. > **La revisión de accesos no es opcional** Conceder acceso es fácil y revisarlo es tedioso, de modo que los permisos derivan al alza con el tiempo. La certificación periódica de accesos, donde los responsables vuelven a confirmar quién debe conservar qué, es el control que detecta la acumulación de privilegios antes de que lo haga un auditor o un atacante. ## Contexto de gobernanza y normas La IAM se sitúa en el centro de la mayoría de los marcos de seguridad porque el control de acceso es fundamental. ISO/IEC 27001 trata el control de acceso y la gestión de identidades como áreas de control esenciales de un sistema de gestión de la seguridad de la información, esperando que las organizaciones definan una política de control de acceso, gestionen el acceso de los usuarios a lo largo de todo el ciclo de vida y revisen los derechos de acceso. El NIST Cybersecurity Framework sitúa la gestión de identidades y el control de acceso entre las funciones de protección que todo programa debería cubrir. Para los datos regulados, la disciplina de acceso también respalda las obligaciones de privacidad bajo el GDPR, ya que limitar quién puede alcanzar los datos personales forma parte de demostrar medidas técnicas apropiadas. Lo que hacen realmente los profesionales lo refleja. Construyen fuentes de identidad autorizadas, automatizan el aprovisionamiento y el desaprovisionamiento, centralizan la autenticación mediante el single sign-on, modelan los permisos como roles cuando es posible, ejecutan revisiones de acceso recurrentes y mantienen un registro de auditoría de quién recibió qué y por qué. Bien hecha, la IAM es invisible para los usuarios y demostrable ante los auditores. Mal hecha, es la causa raíz silenciosa detrás de una gran parte de las brechas. --- ## Gestión de la Continuidad del Negocio (BCM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/bcm **Last reviewed:** 2026-06-24 BCM es la disciplina que identifica las amenazas a las operaciones críticas y diseña los planes y procedimientos para mantenerlas en funcionamiento durante una interrupción. No es un proyecto puntual. El equipo de BCM que responde eficazmente ante un incidente real es el que realizó un ejercicio de simulación cuatro meses antes y registró por escrito lo que falló. ## Qué cubre realmente la gestión de la continuidad del negocio La gestión de la continuidad del negocio es la disciplina de gestión que mantiene en funcionamiento las actividades más importantes de una organización, o las restablece rápidamente, cuando algo va mal. El desencadenante puede ser un incidente cibernético, el colapso de un proveedor, una inundación, un corte de energía o una pandemia. No es necesario prever la amenaza por su nombre. Lo que importa es que la actividad que esa amenaza dejaría fuera de servicio haya sido identificada, priorizada y dotada de un plan probado para recuperarla dentro de un plazo aceptable. El alcance es deliberadamente amplio. La gestión de la continuidad del negocio contempla las personas, las instalaciones, la tecnología, los proveedores y la información, no solo el parque informático. Esa es la primera cosa que la distingue de la recuperación ante desastres, que es el subconjunto centrado en la informática que se ocupa de restaurar la infraestructura, las aplicaciones y los datos. Un banco puede restaurar todos los servidores y aun así no poder operar porque el centro de llamadas no tiene dónde ubicarse y el tercero que valora sus operaciones está fuera de servicio. La gestión de la continuidad del negocio es responsable de ese panorama completo. También es un ciclo continuo, no un proyecto con fecha de finalización. Los planes quedan desactualizados en cuanto una organización se reorganiza, adopta un nuevo sistema o incorpora a un nuevo proveedor crítico. Los equipos que rinden ante un incidente real son los que ensayaron un escenario recientemente y registraron lo que falló, para luego corregirlo antes de la siguiente ronda. ## El ciclo de vida fundamental de la gestión de la continuidad del negocio La mayoría de los programas siguen una secuencia reconocible, reflejada en la norma internacional ISO 22301: 1. Análisis de impacto en el negocio. El estudio estructurado que clasifica cada actividad según la gravedad con que la interrupción la perjudica a lo largo del tiempo y produce los objetivos de recuperación. 1. Evaluación de riesgos. Identificar las amenazas y vulnerabilidades con mayor probabilidad de interrumpir las actividades priorizadas. 1. Estrategia y soluciones. Decidir cómo mantener las actividades en funcionamiento o recuperarlas: sitios alternativos, soluciones provisionales, redundancia, diversificación de proveedores. 1. Planes y procedimientos. Redactar el plan de continuidad del negocio, la estructura de respuesta a incidentes y los manuales de recuperación que las personas usarán realmente bajo presión. 1. Ejercicios y revisión. Ejercicios de simulación teórica y pruebas en vivo, revisiones posteriores a incidentes y auditorías que reincorporan las correcciones al ciclo. > **Las cifras vienen del negocio, no de la sala de servidores** Los objetivos de tiempo de recuperación y de punto de recuperación pertenecen a las personas responsables del proceso, validados mediante el análisis de impacto en el negocio. Los objetivos de RTO y RPO que un equipo tecnológico fija de forma aislada son los que fallan cuando una interrupción real los pone a prueba. ## El lugar de la gestión de la continuidad del negocio en el panorama regulatorio La continuidad ha pasado de ser una buena práctica a una obligación supervisada en varios sectores. ISO 22301 especifica los requisitos de un sistema de gestión de la continuidad del negocio certificable y es la referencia con la que se alinean la mayoría de las organizaciones. En la Unión Europea, el Digital Operational Resilience Act establece expectativas de continuidad y de pruebas para las entidades financieras, y la Directiva NIS 2 exige medidas de continuidad del negocio, incluidas las copias de seguridad y la gestión de crisis, a los operadores de sectores esenciales e importantes. La certificación no es obligatoria para hacer bien la gestión de la continuidad del negocio, pero ofrece a los auditores, los reguladores y los grandes clientes una base reconocida. Busque o no un certificado un programa, se aplican las mismas disciplinas: conocer las actividades críticas, fijar objetivos de recuperación defendibles, redactar planes utilizables y demostrar que funcionan probándolos. --- ## Gestión de parches **URL:** https://cyberacademy.net/es/resources/encyclopedia/patch-management **Last reviewed:** 2026-06-24 La gestión de parches es el proceso operativo que toma una corrección publicada y la aplica en todo el entorno, con un SLA definido y verificación. Con frecuencia es el eslabón más débil: los parches de emergencia colisionan con las ventanas de cambio, la compatibilidad con proveedores y las dependencias de terceros. La auditoría siempre solicita el SLA, la lista de excepciones y las métricas. ## Del parche publicado al parque desplegado El patch management es la disciplina operativa que cierra la brecha entre el momento en que un proveedor publica una corrección y el momento en que esa corrección se ejecuta realmente en cada máquina afectada que usted posee. Un parche puede ser una actualización de seguridad, una corrección de errores o una revisión de firmware, y puede aplicarse a sistemas operativos, aplicaciones, hipervisores, equipos de red, contenedores o controladores industriales. El proceso rara vez consiste en el acto único de instalar una actualización. Consiste en hacerlo a escala, en un orden controlado, sin romper los servicios que dependen de los sistemas que se modifican. Por eso los equipos maduros lo tratan como un workflow definido en lugar de una reacción improvisada ante cada nuevo aviso. Un ciclo viable tiene etapas reconocibles. Inventaría el parque para saber de qué es responsable, ingiere y clasifica los avisos para saber qué parches le importan, prueba en un entorno representativo, despliega mediante la gestión de cambios según un acuerdo de nivel de servicio definido, y verifica que el parche está presente y que el sistema sigue funcionando. Cada etapa produce evidencias, y son esas evidencias las que convierten una intención optimista en un control auditable. ## Por qué es tan a menudo el eslabón más débil Sobre el papel, el patch management parece sencillo. En la práctica, es donde los buenos programas de seguridad fracasan en silencio. La shortDefinition nombra a los culpables habituales, y cada uno es una tensión operativa real. Los parches de emergencia llegan fuera de ciclo y chocan con las ventanas de cambio que mantienen estable la producción, de modo que la corrección urgente espera detrás del calendario. La compatibilidad del proveedor significa que un parche para un componente puede romper otro, que es exactamente por lo que existen las pruebas y por lo que las pruebas requieren un tiempo del que quizá no disponga durante un evento de explotación activa. Las dependencias de terceros y transitivas ocultan código afectado dentro de productos que usted no escribió, de modo que parchea una biblioteca solo para descubrir que una docena de aplicaciones siguen incorporando la versión vulnerable. El resultado es un acumulado de sistemas que no pueden parchearse de inmediato y un conjunto de decisiones sobre qué riesgos asumir. Eso es normal. Lo que distingue un programa controlado de uno expuesto es si esas decisiones son deliberadas, documentadas y acotadas en el tiempo, o si son simplemente cosas de las que nadie se ocupó. La cobertura de activos importa tanto como la velocidad de parcheo: un servidor sin parchear que olvidó que poseía es más peligroso que uno conocido que decidió aplazar. > **La excepción es el control** Cuando un sistema no puede parchearse a tiempo, la respuesta no es el silencio. Es una excepción registrada con una justificación de negocio, un control compensatorio, un responsable y una fecha de caducidad. Una lista de excepciones que se revisa es buena gestión de riesgos. Un acumulado que nadie rastrea no es más que exposición no gestionada que lleva un plazo ya vencido. ## Patch management frente a vulnerability management Estos dos términos viajan juntos y a menudo se confunden, pero responden a preguntas distintas. El vulnerability management trata de saber: descubrir debilidades en todo el parque, evaluarlas y priorizarlas por riesgo, y decidir qué hacer. El patch management trata de actuar: es una de las vías de remediación que cierra una vulnerabilidad, junto con los cambios de configuración, las mitigaciones y el virtual patching. No toda vulnerabilidad se corrige con un parche, y no todo parche cierra una vulnerabilidad de seguridad, de modo que los dos procesos se solapan sin ser lo mismo. **Patch management vs vulnerability management** | Dimensión | Patch management | Vulnerability management | | --- | --- | --- | | Pregunta central | ¿Está el parche desplegado en todas partes donde debería estarlo? | ¿Qué debilidades tenemos y cuáles importan más? | | Entrada principal | Parches y actualizaciones de los proveedores | Escaneos, avisos, threat intelligence, contexto de activos | | Salida principal | Sistemas parcheados y verificados según un SLA | Un acumulado de remediación priorizado y jerarquizado por riesgo | | Alcance | Remediación mediante la aplicación de actualizaciones | Descubrimiento, evaluación, priorización y supervisión de la remediación | En un programa sano se alimentan mutuamente. El vulnerability management le dice qué parches merecen saltar la cola, y el patch management informa de qué correcciones se enviaron realmente, de modo que el siguiente escaneo debería volver limpio. Cuando se ejecutan como silos separados, las vulnerabilidades se clasifican en informes que ningún proceso de despliegue consume. ## Lo que pedirán un auditor y un regulador El patch management es uno de los controles operativos más directamente examinados porque la evidencia es concreta. Respalda objetivos de control en el marco de un sistema de gestión de la seguridad de la información ISO/IEC 27001, en particular los que cubren las vulnerabilidades técnicas y la gestión de cambios, y sustenta las expectativas de configuración segura y mantenimiento integradas en marcos como el NIST Cybersecurity Framework y conjuntos de controles como los CIS Controls. Regulaciones como NIS2 y DORA presuponen que una organización puede demostrar una remediación oportuna de las debilidades conocidas, y el patch management es la forma en que se hace esa demostración. Las preguntas son predecibles, por eso la shortDefinition las enumera. Espere mostrar la política de parcheo y el SLA que define con qué rapidez deben desplegarse los distintos niveles de gravedad, la lista de excepciones con justificaciones y responsables, y las métricas que prueban que el proceso funciona: porcentaje de activos parcheados dentro del SLA, tiempo medio de parcheo, antigüedad de la excepción abierta más antigua, y cobertura del inventario de activos. Si puede producirlas sin apuros, su programa es real. Si no puede, la auditoría habrá encontrado el eslabón más débil antes que cualquier atacante. --- ## Gestión de vulnerabilidades **URL:** https://cyberacademy.net/es/resources/encyclopedia/vulnerability-management **Last reviewed:** 2026-06-24 La gestión de vulnerabilidades es el ciclo de descubrimiento, priorización, remediación y verificación de vulnerabilidades en el entorno tecnológico. Los escáneres detectan miles; la disciplina reside en la priorización (criticidad del activo + disponibilidad de exploit + exposición al negocio) y no en el propio escaneo. CVE, CVSS y KEV son el vocabulario del campo. ## Un ciclo, no un escaneo La gestión de vulnerabilidades suele reducirse a «ejecutar el escáner», pero el escaneo es la parte fácil. La disciplina es un ciclo que se repite: mantener un inventario preciso de lo que se posee, descubrir las debilidades de esos activos, priorizar el puñado que realmente importa, remediarlas y verificar que la corrección se mantuvo. Un escáner moderno te entregará miles de hallazgos sobre un parque mediano. Tratar esa lista como una cola de tareas es la forma en que los equipos se agotan mientras su exposición real sigue abierta. El valor está en el embudo, desde miles de hallazgos en bruto hasta el pequeño conjunto sobre el que actúas esta semana. También depende de algo que la mayoría de los equipos subestima: conocer tu parque. Una vulnerabilidad en un servidor expuesto a Internet que ejecuta una aplicación de negocio crítica es un problema distinto del mismo defecto en una máquina de pruebas aislada. Sin inventario de activos ni propiedad, la priorización no tiene nada en lo que apoyarse, por lo que el ciclo comienza con el descubrimiento y la identificación en lugar de con el escaneo en sí. ## El vocabulario: CVE, CVSS y KEV Tres puntos de referencia sostienen la mayor parte de la conversación sobre priorización, y los profesionales los usan en combinación más que de forma aislada. **Cómo se usan CVE, CVSS y KEV** | Término | Qué es | Qué te indica | | --- | --- | --- | | CVE | Un identificador único para una vulnerabilidad divulgada públicamente | Un nombre común para que todos hablen del mismo defecto en las distintas herramientas y avisos de seguridad. | | CVSS | Un marco de puntuación que califica la gravedad | Cuán grave es el defecto en teoría, según su impacto y sus características de explotabilidad. Un punto de partida, no un veredicto. | | KEV | Un catálogo de vulnerabilidades conocidas por estar siendo explotadas en la práctica | Si los atacantes la están usando realmente ahora, lo que eleva considerablemente la prioridad en el mundo real. | El error común es ordenar por puntuación CVSS y trabajar de arriba hacia abajo. Un CVSS alto en un activo que nadie puede alcanzar importa menos que un defecto de gravedad media que figura en un catálogo de vulnerabilidades conocidas por estar siendo explotadas en un sistema expuesto. Los programas maduros combinan la gravedad teórica con señales reales: existe un exploit funcional, se está explotando activamente la vulnerabilidad, y cuán expuesto y crítico es el activo afectado. Esa combinación, no la puntuación en bruto, es lo que impulsa la cola. ## La priorización es todo el trabajo El planteamiento honesto es que la priorización es el producto de la gestión de vulnerabilidades. Las entradas son la criticidad del activo, la disponibilidad de un exploit y la exposición del negocio, y la salida es una decisión defendible sobre qué se corrige primero y qué espera. Aquí es donde la función justifica su valor, porque ningún equipo puede ni debe remediarlo todo a la vez. 1. Criticidad del activo: qué hace el sistema para el negocio y qué puede alcanzar si se ve comprometido. 1. Disponibilidad de un exploit: si existe un exploit funcional y si el defecto se está usando en la práctica. 1. Exposición del negocio: si el activo está expuesto a Internet, qué datos contiene y qué controles compensatorios ya se interponen delante de él. > **Dónde termina la gestión de vulnerabilidades y dónde comienza la gestión de parches** La gestión de vulnerabilidades decide qué corregir y en qué orden. La gestión de parches es la maquinaria operativa que toma una corrección publicada y la despliega por todo el parque según un SLA, con verificación. Son dos mitades de un mismo resultado: la primera prioriza, la segunda entrega, y el paso de verificación cierra el círculo de vuelta al escáner. ## Dónde encaja en la gobernanza La gestión de vulnerabilidades rara vez es opcional una vez que estás dentro de un marco reconocido. Un SGSI ISO/IEC 27001 espera un proceso definido para gestionar las vulnerabilidades técnicas, y los auditores pedirán ver el ciclo en funcionamiento, no solo una licencia de escáner. El NIST Cybersecurity Framework considera la identificación y gestión de vulnerabilidades como algo central de las funciones Identify y Protect, y normativas como NIS2 y DORA dan por sentado que las organizaciones encuentran y remedian activamente las debilidades en lugar de esperar a que un incidente las revele. En todos los casos, la evidencia que quiere un evaluador tiene la misma forma: cómo descubres, cómo priorizas, los SLA con los que remedias y las métricas que demuestran que el ciclo se está cerrando. --- ## Gestión del Riesgo de Terceros (TPRM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/tprm **Last reviewed:** 2026-06-24 TPRM es la disciplina que gobierna el riesgo introducido por proveedores, subcontratistas y prestadores de servicios. Diligencia debida en la incorporación, cláusulas contractuales, supervisión continua y desvinculación. Obligatoria bajo NIS 2 (seguridad de la cadena de suministro) y DORA (riesgo de terceros TIC). El incidente de Crowdstrike y el de SolarWinds convirtieron el TPRM en un asunto de agenda del consejo de administración. La Gestión del Riesgo de Terceros (TPRM) trata a sus proveedores, subcontratistas y prestadores de servicios como una extensión de su propia superficie de ataque. La lógica es simple: si un proveedor procesa sus datos, opera su infraestructura o forma parte de su cadena de suministro, entonces sus debilidades se convierten en sus incidentes. El TPRM es la disciplina que hace que esa exposición sea visible, contractual y supervisada de forma continua, en lugar de descubierta en el momento de la brecha. ## Las cuatro fases que los profesionales ejecutan realmente El TPRM no es un cuestionario puntual. Es un ciclo de vida que abarca desde el primer contacto con un proveedor hasta el día en que se le desconecta. La mayoría de los programas maduros lo estructuran en cuatro fases: - Diligencia debida de incorporación. Antes de firmar, se evalúa al proveedor en función del riesgo que introduce. Un proveedor SaaS que aloja datos personales y un proveedor de material de oficina no reciben el mismo escrutinio. La clasificación por criticidad es lo que evita que el programa se desborde. - Cláusulas contractuales. El contrato es donde la garantía se vuelve exigible: obligaciones de seguridad, derechos de auditoría, plazos de notificación de brechas, divulgación de subprocesadores, ubicación de los datos y condiciones de salida. Si no está en el contrato, no podrá exigirlo después. - Garantía continua. El riesgo no se congela en la firma. La cadencia de reevaluación, el seguimiento de certificados (ISO 27001, SOC 2), la supervisión continua de la postura de seguridad del proveedor y la revisión de las dependencias de cuarta parte mantienen el panorama actualizado. - Desvinculación. Cuando la relación termina, se recupera o se confirma la destrucción de los datos, se revocan los accesos y se cierra la exposición residual. Es la fase que los equipos omiten con más frecuencia, y la que deja credenciales huérfanas atrás. ## Por qué se convirtió en una conversación a nivel de consejo de administración El TPRM solía residir en compras. Pasó al consejo de administración porque los fallos más sonados de la última década llegaron a través de la cadena de suministro, no por la puerta principal. El incidente de SolarWinds mostró a un atacante alcanzando a miles de organizaciones al comprometer una única actualización de software de confianza. La caída de CrowdStrike demostró que una actualización defectuosa de un único proveedor crítico podía detener las operaciones de sectores enteros a la vez. Ambos replantearon a los terceros como un riesgo sistémico, no como una casilla de verificación de compras. La regulación lo siguió. NIS 2 convierte la seguridad de la cadena de suministro en un deber explícito para las entidades incluidas en su ámbito y responsabiliza a los órganos de dirección de los fallos. DORA va más allá para las entidades financieras, dedicando uno de sus cinco pilares al riesgo de terceros proveedores de TIC, imponiendo requisitos contractuales específicos y sometiendo a los propios proveedores críticos de TIC a supervisión. Para una empresa regulada, el TPRM ya no es una buena práctica, es una obligación documentada. > **Una tercera parte no es una cuarta parte** Su proveedor directo es la tercera parte. Sus proveedores son sus cuartas partes, y rara vez los ve. El riesgo de concentración se esconde aquí: muchos de sus proveedores pueden depender de la misma región de cloud o de la misma biblioteca de origen. Mapear esa cadena de dependencias es lo que separa un programa de mero trámite de uno real. ## En qué se diferencia el TPRM de las disciplinas vecinas El TPRM convive con la gestión de proveedores y la gestión de riesgos en general, pero es más estrecho y más preciso que cualquiera de ellas. La gestión de proveedores optimiza el coste, el rendimiento y la relación comercial. El TPRM se ocupa específicamente del riesgo de seguridad, resiliencia, privacidad y cumplimiento que introduce una tercera parte. También se diferencia del trabajo interno del SGSI: sus controles se detienen en su perímetro, pero su responsabilidad no. Puede externalizar la actividad, no puede externalizar el riesgo. Esa asimetría es la razón misma por la que existe la disciplina. --- ## ISO 19011 (ISO 19011) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-19011 **Last reviewed:** 2026-06-24 ISO 19011 es la norma de directrices para la auditoría de sistemas de gestión. De aplicación genérica: cubre igualmente las auditorías de ISO 27001, 9001 y 22301. Define los principios de auditoría, la gestión del programa de auditoría, el ciclo de auditoría y la competencia del auditor. El curso Lead Auditor la enseña; los auditores que se encuentran en el campo se formaron con ella. ## Qué cubre realmente la ISO 19011 La ISO 19011 es el documento de referencia para cualquier persona que planifica, realiza o gestiona auditorías de sistemas de gestión. Es deliberadamente genérica, de modo que los mismos principios se aplican tanto si audita un sistema de gestión de la seguridad de la información frente a la ISO 27001, un sistema de calidad frente a la ISO 9001 o la continuidad de negocio frente a la ISO 22301. En lugar de indicarle los requisitos que una organización debe cumplir, le explica cómo observar esos requisitos como auditor : cómo construir un programa de auditoría, cómo llevar a cabo una auditoría individual desde la reunión de apertura hasta la de cierre, y cómo juzgar si las personas que realizan la auditoría son competentes. La norma organiza la auditoría en torno a un pequeño conjunto de principios. La integridad y la presentación imparcial mantienen la honestidad de los hallazgos. El debido cuidado profesional y la confidencialidad protegen a las personas y la información implicadas. Un enfoque basado en la evidencia significa que las conclusiones se apoyan en registros y observaciones verificables, no en impresiones ; y el pensamiento basado en el riesgo añadido en las revisiones recientes impulsa a los auditores a concentrar el esfuerzo donde más importa para los objetivos. ## Programa de auditoría, ciclo de la auditoría y competencia Una forma útil de leer la ISO 19011 es verla como tres capas anidadas. En la cima se sitúa el programa de auditoría, el conjunto de auditorías planificadas durante un periodo y la gestión de ese programa : fijar objetivos, asignar recursos, supervisar resultados y mejorar con el tiempo. En su interior se sitúa la auditoría individual y su ciclo : - Iniciar la auditoría y confirmar su viabilidad con el auditado. - Preparar las actividades de auditoría, incluida la revisión documental y el plan de auditoría. - Realizar la auditoría en sitio o de forma remota : reunión de apertura, recopilación y verificación de la evidencia, generación de hallazgos. - Informar, incluidas las conclusiones y la reunión de cierre. - Finalizar la auditoría y realizar cualquier seguimiento de las acciones correctivas. La tercera capa es la competencia del auditor. La ISO 19011 plantea la competencia como una combinación de comportamiento personal, conocimientos y habilidades genéricas de auditoría, y conocimientos propios de una disciplina, y a continuación describe cómo evaluarla y mantenerla. Por eso un profesional de la seguridad no puede limitarse a leer la norma una sola vez. La competencia es algo que se construye mediante la formación, la observación de auditorías y la práctica continua. > **Directrices, no certificación** La ISO 19011 es una norma de directrices, por lo que no se certifica frente a ella del mismo modo que una organización se certifica frente a la ISO 27001. Cuando se certifica un sistema de gestión, el organismo de certificación trabaja conforme a la ISO/IEC 17021-1, que se apoya en los mismos conceptos de auditoría. ## Dónde la encuentran los profesionales En la práctica, usted se encuentra con la ISO 19011 en dos roles. Como auditado, explica lo que un auditor competente hará y no hará, lo que le ayuda a preparar la evidencia y a cuestionar hallazgos poco sólidos. Como auditor, interno o frente a proveedores, es el manual que sigue para hacer las auditorías repetibles y defendibles. El curso de Lead Auditor enseña esta norma junto con los requisitos del sistema que se audita, y los auditores externos que conoce durante la certificación se formaron con el mismo material. --- ## ISO 22301 (ISO 22301) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-22301 **Last reviewed:** 2026-06-24 ISO 22301 es la norma internacional para los sistemas de gestión de la continuidad del negocio (BCMS). Especifica los requisitos para planificar, operar, supervisar y mejorar un BCMS que permita reanudar las operaciones críticas tras una interrupción. Los reguladores financieros la exigen cada vez más desde DORA, y los supervisores de NIS 2 la requieren a los operadores de servicios esenciales. ## Lo que ISO 22301 realmente exige ISO 22301 es la norma de requisitos para un sistema de gestión de la continuidad del negocio, un SGCN. La palabra sistema importa. No es un plan que se redacta una vez y se archiva, sino un ciclo gestionado: comprendes lo que hace tu organización, decides qué actividades no puedes permitirte perder durante mucho tiempo, construyes la capacidad para mantenerlas en funcionamiento o recuperarlas con rapidez, y luego mantienes esa capacidad fiable mediante ejercicios, revisiones y mejoras. Al tratarse de una norma de requisitos, una organización puede ser auditada y certificada conforme a ella por un organismo acreditado, que es lo que da a un cliente o a un regulador algo concreto en lo que confiar. Al igual que ISO 27001 y las demás normas modernas de sistemas de gestión ISO, ISO 22301 sigue la High-Level Structure. Eso significa que comparte el mismo esqueleto: contexto de la organización, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora, todo ello sobre un ciclo Plan-Do-Check-Act. En la práctica esto es una ventaja, porque si ya operas un sistema de gestión de la seguridad de la información reutilizas la misma gobernanza, el mismo lenguaje de riesgo, la misma maquinaria de auditoría interna, y añades la continuidad por encima en lugar de construir una estructura paralela. ## El trabajo detrás del certificado Tres actividades se sitúan en el centro de un programa ISO 22301, y un profesional dedica aquí la mayor parte de su tiempo en lugar de a la documentación: - Análisis de impacto en el negocio. El BIA identifica tus actividades prioritarias y determina con qué rapidez debe restablecerse cada una. Es lo que produce los objetivos de tiempo de recuperación que rigen toda decisión posterior. Sin un BIA defendible, tu estrategia de continuidad es pura conjetura. - Evaluación de riesgos. Examinas qué podría interrumpir esas actividades prioritarias, desde un brote de ransomware hasta el fallo de un proveedor o un centro de datos inundado, para que tu estrategia responda a amenazas reales en lugar de a una lista de comprobación genérica. - Estrategia y planes de continuidad. A partir del BIA y del panorama de riesgos, eliges cómo proteger y recuperar cada actividad, y luego redactas y dotas de recursos los procedimientos que las personas siguen realmente cuando todo se apaga. > **La continuidad es más amplia que la recuperación de TI** ISO 22301 abarca toda la organización, no solo los sistemas. Las personas, las instalaciones, los proveedores y los procesos cuentan todos. La recuperación de TI ante desastres es una de las entradas a la continuidad, la parte que restaura la tecnología, pero el SGCN plantea una pregunta más amplia: ¿puede el negocio seguir entregando sus productos y servicios críticos, por cualquier medio, mientras la recuperación técnica está en curso? ## Por qué los reguladores apuntan cada vez más hacia ella ISO 22301 era antes una discreta norma de resiliencia operativa que las organizaciones maduras adoptaban por elección. Eso ha cambiado. Como señala la shortDefinition, los reguladores financieros que se apoyan en DORA y los supervisores que hacen cumplir NIS 2 esperan ahora una capacidad de continuidad demostrable para las operaciones críticas, e ISO 22301 es la forma más reconocida de evidenciarla. La norma no menciona ninguna regulación específica, pero su disciplina, actividades prioritarias, objetivos de recuperación definidos, planes probados, dependencias mapeadas, encaja con precisión en lo que esos regímenes exigen. Certificarse conforme a ella permite a una organización responder a un supervisor con una atestación independiente en lugar de una autoevaluación. Una confusión frecuente es la relación con ISO 27001. Son hermanas, no sustitutas. ISO 27001 gobierna la seguridad de la información, protegiendo la confidencialidad, la integridad y la disponibilidad de la información. ISO 22301 gobierna la continuidad, manteniendo el negocio en funcionamiento a través de la perturbación. La disponibilidad es el puente: una organización seria en materia de resiliencia a menudo opera ambas, las certifica juntas para compartir auditorías y revisiones por la dirección, y trata la continuidad como la respuesta a la pregunta que la seguridad por sí sola no puede resolver, que es qué ocurre cuando la prevención falla y aun así tienes que entregar. **ISO 22301 junto a ISO 27001** | Dimensión | ISO 22301 | ISO 27001 | | --- | --- | --- | | Objeto | Sistema de gestión de la continuidad del negocio | Sistema de gestión de la seguridad de la información | | Pregunta central | ¿Podemos seguir entregando las actividades críticas bajo una perturbación? | ¿Estamos protegiendo nuestros activos de información? | | Artefactos definitorios | Análisis de impacto en el negocio, estrategia de continuidad, planes probados | Tratamiento del riesgo, Declaración de aplicabilidad, controles | | Desencadenante al que responde | Ha ocurrido una perturbación, recuperar y continuar | Una amenaza a la información, prevenir y proteger | | Terreno compartido | High-Level Structure, PDCA, certificable, a menudo operadas juntas | High-Level Structure, PDCA, certificable, a menudo operadas juntas | --- ## ISO 31000 (ISO 31000) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-31000 **Last reviewed:** 2026-06-24 ISO 31000 es la norma genérica de gestión de riesgos. Principios, marco de referencia y proceso iterativo. NO es un sistema de gestión certificable; no existe el ISO 31000 Lead Auditor, a pesar de lo que afirman algunos catálogos. El itinerario PECB es Foundation → Risk Manager → Lead Risk Manager. Se utiliza cuando la gestión del riesgo abarca un alcance más amplio que la seguridad de la información. ## Una norma genérica, no un sistema de gestión ISO 31000 es la referencia internacional para gestionar el riesgo de cualquier tipo, en cualquier organización. Es deliberadamente genérica. Los mismos principios, el mismo marco de referencia y el mismo proceso se aplican tanto si el riesgo en cuestión es financiero, operativo, estratégico, de seguridad, ambiental o cibernético. Esa amplitud es precisamente el objetivo. Una decisión de compra, la entrada en un nuevo mercado y una exposición a un ransomware pueden evaluarse todas con el mismo vocabulario y la misma lógica, lo que permite a un consejo de administración comparar riesgos que de otro modo quedarían en silos separados con valoraciones incompatibles. El malentendido más frecuente es tratar ISO 31000 como ISO 27001 o ISO 22301. No es una norma de requisitos y no es certificable. No existe ningún sistema de gestión ISO 31000 que auditar ni ninguna cualificación de Auditor Líder ISO 31000, por mucho que algunos catálogos de formación lo anuncien. La norma ofrece directrices que adaptar, no requisitos a los que conformarse. Las organizaciones la integran en su forma de operar actual, en lugar de añadir un sistema certificado independiente. ## Principios, marco de referencia y proceso ISO 31000 se construye sobre tres partes conectadas que los profesionales aprenden a mantener diferenciadas. Los principios establecen cómo es una buena gestión del riesgo: está integrada en la organización, estructurada, adaptada al contexto, inclusiva con las partes interesadas, dinámica, basada en la mejor información disponible y orientada a crear y proteger valor. El marco de referencia trata del liderazgo y la gobernanza, de cómo se ordena, se diseña, se implementa, se evalúa y se mejora la gestión del riesgo a lo largo del tiempo para que realmente arraigue. El proceso es el motor operativo que se ejecuta de forma repetida. 1. Establecer el contexto. Definir el alcance, los objetivos y el entorno interno y externo en el que vive el riesgo. 1. La identificación, el análisis y la evaluación del riesgo, que juntos forman la apreciación del riesgo. 1. El tratamiento del riesgo. Elegir cómo modificar el riesgo y, después, implementar y verificar los controles. 1. La comunicación, la consulta, el seguimiento y la revisión, que envuelven todo el ciclo y lo mantienen actualizado. > **Úsala cuando el riesgo es más amplio que la seguridad de la información** ISO 31000 te aporta el lenguaje paraguas para el riesgo a nivel de toda la organización. Cuando te centras específicamente en el riesgo de seguridad de la información, recurres a una norma sectorial como ISO 27005 o a un método como EBIOS Risk Manager, que se sitúan cómodamente por debajo del proceso ISO 31000. ## Cómo se relaciona con normas vecinas ISO 31000 es la norma matriz. ISO 27005 aplica la misma lógica de proceso al riesgo de seguridad de la información y se alinea con un sistema de gestión de seguridad de la información ISO 27001. EBIOS Risk Manager, el método francés publicado por ANSSI, es una forma concreta y guiada por escenarios de realizar una apreciación del riesgo de seguridad que se corresponde con las mismas etapas. Ninguno de estos contradice ISO 31000; la especializan. Un risk manager que comprende el proceso genérico puede moverse entre ellos sin volver a aprender los fundamentos, razón por la cual la norma se enseña primero. El vocabulario se comparte a través de la Guía ISO 73, el documento complementario que define los términos de la gestión del riesgo para que «probabilidad», «consecuencia» y «tratamiento del riesgo» signifiquen lo mismo en todos los documentos y equipos. Acordar pronto esas definiciones evita las discusiones sobre valoración que descarrilan muchos talleres de riesgo. ## Qué hacen realmente los profesionales con ella En la práctica, ISO 31000 da forma al registro de riesgos, a los talleres de apreciación y a la línea de reporte hacia la dirección. Un risk manager la utiliza para justificar por qué un riesgo se asigna, se valora y se trata de determinada manera, y para demostrar que el enfoque es coherente en lugar de improvisado caso por caso. Como la norma no es certificable, la forma reconocida de demostrar competencia es a través de una credencial personal. El itinerario de PECB recorre Foundation, luego Risk Manager y luego Lead Risk Manager, avanzando desde el conocimiento de los conceptos hasta liderar un programa de gestión del riesgo en toda una organización. --- ## ISO/IEC 27001 (ISO 27001) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27001 **Last reviewed:** 2026-06-24 ISO 27001 es el marco certificable que los auditores utilizan para evaluar la seguridad de la información. La revisión de 2022 redujo el Anexo A a 93 controles distribuidos en cuatro categorías (organizativas, de personas, físicas y tecnológicas). El SGSI se sostiene o cae por la Declaración de Aplicabilidad y las evidencias de operación. Todo el mundo lo referencia; pocos lo gestionan bien. ## Qué certifica realmente la ISO/IEC 27001 La ISO/IEC 27001 es la norma internacional que especifica los requisitos de un sistema de gestión de la seguridad de la información, o SGSI. El certificado no afirma que sus sistemas sean inviolables. Afirma que un organismo acreditado examinó cómo identifica los riesgos de información, decide qué hacer al respecto y mantiene esa decisión en funcionamiento bajo la supervisión de la dirección. La norma se basa en el ciclo Plan-Do-Check-Act, por lo que la certificación nunca es un evento puntual: usted se compromete con un ritmo recurrente de apreciación del riesgo, tratamiento, auditoría interna, revisión por la dirección y acción correctiva. Una confusión habitual es tratar los controles del Anexo A como si fueran la norma. No lo son. Los requisitos certificables residen en las cláusulas numeradas del sistema de gestión (contexto, liderazgo, planificación, apoyo, operación, evaluación del desempeño, mejora). El Anexo A es un conjunto de referencia de controles entre los que usted selecciona. Puede superar una auditoría sin implementar todos los controles, siempre que su Declaración de aplicabilidad justifique lo que excluyó y sus evidencias respalden lo que conservó. ## La revisión de 2022 y los temas de controles La revisión de 2022 reorganizó el Anexo A en cuatro temas en lugar de los anteriores catorce dominios. Los temas agrupan los controles según el tipo de elemento que se protege o gobierna: - Los controles organizativos abarcan políticas, relaciones con proveedores, inteligencia de amenazas y seguridad de la información en la gestión de proyectos. - Los controles relativos a las personas abarcan la verificación, las condiciones de empleo, la concienciación y el proceso disciplinario. - Los controles físicos abarcan las áreas seguras, los equipos, el escritorio despejado y la eliminación de soportes. - Los controles tecnológicos abarcan la gestión de accesos, la criptografía, el registro de eventos, el desarrollo seguro y la gestión de configuraciones. Si se certificó bajo la versión anterior, el trabajo de transición es en su mayor parte un ejercicio de reasignación: recartografiar su Declaración de aplicabilidad frente al nuevo conjunto de controles, confirmar que nada se cayó por las brechas creadas por controles fusionados o nuevamente introducidos, y actualizar las referencias de evidencia. Las cláusulas del sistema de gestión cambiaron mucho menos que el anexo. > **La SoA es donde se ganan o se pierden las auditorías** Las no conformidades de la etapa 2 provienen con mayor frecuencia de la divergencia entre la Declaración de aplicabilidad, el plan de tratamiento del riesgo y lo que la organización realmente hace. Mantenga los tres documentos conciliados y la auditoría se convierte en un ejercicio de verificación en lugar de un ejercicio de descubrimiento. ## Cómo se sitúa junto a sus vecinas La ISO 27001 es el ancla certificable de una familia. La ISO 27002 ofrece orientación de implementación para los mismos controles del Anexo A, pero no es certificable por sí sola; los auditores recurren a ella cuando quieren cuestionar la calidad con la que opera un control, no simplemente si existe. La ISO 27005 aporta un método para la apreciación del riesgo de seguridad de la información que la cláusula 6 exige pero deja deliberadamente abierto. El SGSI es la máquina en funcionamiento que la norma certifica, y la SoA es su artefacto controlado central. En el lado de las personas, el trabajo se divide en dos disciplinas complementarias. Los implementadores construyen y operan el sistema de gestión. Los auditores planifican y dirigen las auditorías que lo ponen a prueba, trabajando conforme a la orientación de auditoría de la ISO 19011. La mayoría de las funciones de seguridad maduras necesitan ambas mentalidades, incluso cuando una sola persona lleva los dos sombreros al principio. ## Qué hacen realmente los profesionales Operar bien la ISO 27001, en lugar de simplemente superar el certificado, se ve así en la práctica: 1. Definir el alcance con honestidad. Un alcance demasiado amplio lo sepulta en evidencias; uno demasiado estrecho no engaña a nadie y socava el certificado. 1. Realizar una apreciación del riesgo y un plan de tratamiento reales, y mantenerlos vigentes a medida que cambian el negocio y el panorama de amenazas. 1. Mantener la Declaración de aplicabilidad como un documento vivo vinculado a evidencias reales, no como una hoja de cálculo completada una sola vez para el auditor. 1. Operar las auditorías internas y las revisiones por la dirección según el calendario, y cerrar las acciones correctivas con pruebas en lugar de promesas. 1. Tratar las auditorías de seguimiento y el ciclo de recertificación como continuidad, no como simulacros separados. --- ## ISO/IEC 27002 (ISO 27002) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27002 **Last reviewed:** 2026-06-24 ISO 27002 es la guía de implementación de los controles del Anexo A de ISO 27001. No es certificable por sí sola. Los auditores la utilizan cuando quieren cuestionar CÓMO se opera un control, no solo si está «implantado». Trátela como el manual operativo que acompaña a la norma de certificación. ## Qué es realmente la norma ISO/IEC 27002 ISO/IEC 27002 es la guía de implementación que acompaña a ISO 27001. Mientras que ISO 27001 es la norma certificable de sistema de gestión que enumera los controles del Anexo A y exige justificar cuáles se aplican, ISO 27002 explica cada uno de esos controles en profundidad: su propósito, cómo es una buena práctica y las consideraciones prácticas de ponerlo en operación. Es un código de buenas prácticas, no una lista de requisitos para marcar. No se certifica frente a ISO 27002 y un auditor no puede emitir una no conformidad directamente contra ella. La utiliza para interpretar el espíritu de un control del Anexo A y para cuestionar si su implementación es realmente adecuada a su finalidad. Esa distinción importa en las auditorías reales. Una revisión superficial pregunta si un control está "implantado". Un auditor que recurre a ISO 27002 pregunta cómo lo opera: si la revisión de accesos ocurre realmente con la cadencia que usted afirma, si su registro captura los eventos que le permitirían detectar un incidente, si sus cláusulas con proveedores sobreviven al contacto con una brecha real. La norma da a ambas partes un vocabulario común para esa conversación, y por eso los profesionales la tratan como el manual operativo en lugar de como una lectura complementaria. ## Cómo se relaciona con ISO 27001, la SoA y el SGSI Los tres documentos forman una cadena. Su SGSI es el sistema de gestión que dirige todo el programa. ISO 27001 define qué debe hacer ese sistema y aporta el conjunto de controles. La Declaración de Aplicabilidad (SoA) registra, control por control, cuáles ha incluido, cuáles ha excluido y por qué. ISO 27002 es a donde acude para conocer el contenido de cada control una vez que la SoA le indica que se aplica. En la práctica, los equipos redactan la SoA con ISO 27001 abierta para el requisito e ISO 27002 abierta para la guía de implementación, y luego diseñan el control real conforme a la guía. > **Usted implementa según 27002, se certifica frente a 27001** Una forma clara de recordar la separación: ISO 27001 le dice qué controles considerar y le obliga a documentar sus decisiones en la SoA. ISO 27002 le dice cómo se supone que funciona cada control. La certificación audita el sistema de gestión y los controles que seleccionó, usando ISO 27002 como referencia de cómo es una implementación competente. Las ediciones modernas de ISO 27002 organizan los controles en cuatro temas, organizativo, de personas, físico y tecnológico, y etiquetan cada uno con atributos como el tipo de control, la propiedad de seguridad que protege y el concepto de ciberseguridad pertinente. Esos atributos le permiten segmentar el conjunto de controles de distintas maneras, por ejemplo extrayendo todos los controles preventivos o todos los que apoyan la detección, lo que ayuda cuando establece correspondencias con otros marcos o construye un plan de tratamiento del riesgo. ## Qué hacen realmente los profesionales con ella En un programa en funcionamiento, ISO 27002 aparece en algunas tareas recurrentes: 1. Diseñar controles: cuando la SoA marca un control como aplicable, la guía de implementación da forma a la política, el procedimiento o la configuración técnica que usted construye. 1. Justificar decisiones: cuando adapta o delimita el alcance de un control, la guía le aporta el fundamento que debe registrar para que un auditor pueda seguir su razonamiento. 1. Prepararse para la auditoría: los equipos usan la guía para poner a prueba sus propios controles antes de que lo haga el evaluador, cerrando la brecha entre "documentado" y "operando con eficacia". 1. Establecer correspondencias entre marcos: la estructura de los controles y los atributos hacen de ISO 27002 una columna vertebral útil para hacer correspondencias con conjuntos de controles como los CIS Controls o las guías del NIST. Como ISO 27002 es una guía y no un requisito estricto, el juicio queda de su parte. La norma describe la intención y la buena práctica; usted decide hasta dónde llegar en función de su evaluación del riesgo. Esa libertad es el objetivo. Permite que una pequeña consultoría y una multinacional reclamen ambas la conformidad con el mismo control, implementándolo a profundidades muy distintas, cada una adecuada a su riesgo. --- ## ISO/IEC 27005 (ISO 27005) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27005 **Last reviewed:** 2026-06-24 ISO 27005 es la metodología de gestión del riesgo de seguridad de la información que se articula sobre ISO 27001. Identificación, análisis, evaluación, tratamiento, aceptación. La revisión de 2022 se alinea con los principios de ISO 31000 y clarifica la relación con el Apartado 6 de ISO 27001. Menos prescriptiva que EBIOS RM, pero es la lingua franca canónica con los auditores. ## Para qué sirve la ISO/IEC 27005 La ISO/IEC 27005 es la norma de orientación para gestionar el riesgo de seguridad de la información. No certifica nada y no sustituye a la ISO/IEC 27001. En cambio, le proporciona un método para realizar la apreciación y el tratamiento del riesgo que el capítulo 6 de la ISO 27001 exige pero deja deliberadamente abiertos. La ISO 27001 le indica que debe identificar, analizar, evaluar y tratar los riesgos de seguridad de la información ; la ISO 27005 le muestra una forma defendible de hacerlo. Esa división del trabajo es lo más importante que hay que entender sobre la norma. El método sigue una trayectoria reconocible : establecer el contexto, identificar los riesgos, analizarlos, evaluarlos frente a sus criterios y, a continuación, tratarlos. El tratamiento concluye con una decisión y un registro, no con una simple lista de controles. Dos resultados importan a los auditores por encima de todos los demás. El primero es su conjunto de criterios de aceptación del riesgo, acordados antes de empezar a puntuar para que los resultados no puedan ajustarse a posteriori hacia una respuesta conveniente. El segundo es la aprobación documentada cuando un riesgo residual es aceptado por el responsable adecuado. Esos artefactos son los que convierten una hoja de cálculo de puntuaciones en un proceso gestionado. ## La revisión de 2022 y el vínculo con la ISO 31000 La revisión actual alinea el vocabulario y la estructura con la ISO 31000, la norma de gestión del riesgo de toda la organización, para que el riesgo de seguridad de la información hable el mismo lenguaje que el riesgo empresarial. También precisa la relación con la ISO 27001 al asociar sus actividades con los capítulos de la ISO 27001 en lugar de describir un universo paralelo. Donde el pensamiento más antiguo se apoyaba en gran medida en enumerar activos, amenazas y vulnerabilidades, la revisión acoge tanto esa visión basada en eventos como una visión basada en escenarios, dando a los equipos margen para apreciar el riesgo de la manera que realmente se ajusta a su entorno. > **Orientaciones, no requisitos** La ISO 27005 emplea la palabra debería, no debe. No puede certificarse frente a ella y un auditor no puede levantar una no conformidad por apartarse de sus pasos exactos. Lo que comprobará es que la apreciación del riesgo que alimenta su SGSI ISO 27001 sea coherente, repetible y esté documentada. La ISO 27005 es la forma más común de demostrarlo. ## La ISO 27005 frente a EBIOS RM Los profesionales en Francia comparan constantemente la ISO 27005 con EBIOS Risk Manager, el método mantenido por la ANSSI. No son tanto rivales como instrumentos diferentes. La ISO 27005 es menos prescriptiva, reconocida internacionalmente y constituye la lengua común con los auditores de certificación, lo que la convierte en la opción natural cuando su objetivo es un certificado ISO 27001 con validez universal. EBIOS RM es más estructurada y orientada a escenarios, construida en torno a escenarios de ataque estratégicos y operativos y a orígenes de riesgo explícitos, lo que se adapta a los contextos franceses de alto riesgo o regulados. Muchas organizaciones aplican EBIOS RM para el análisis y luego expresan los resultados en términos de la ISO 27005 para el SGSI. **La ISO/IEC 27005 comparada con EBIOS Risk Manager** | Dimensión | ISO/IEC 27005 | EBIOS Risk Manager | | --- | --- | --- | | Naturaleza | Norma de orientación internacional | Método nacional mantenido por la ANSSI | | Estilo | Menos prescriptiva, flexible | Estructurada, orientada a escenarios y amenazas | | Mejor encaje | Certificación ISO 27001, reconocimiento mundial | Contextos franceses de alto riesgo y regulados | | Público | Auditores de certificación de todo el mundo | Sector público francés y operadores críticos | ## Lo que los profesionales hacen en realidad Usar bien la ISO 27005, en lugar de producir un documento puntual, en la práctica se parece a esto : 1. Establecer primero el contexto : el alcance, los criterios de impacto y probabilidad, y los umbrales de aceptación del riesgo, todos acordados antes de que comience cualquier puntuación. 1. Identificar los riesgos de la manera que se ajuste al entorno, ya sean cadenas activo-amenaza-vulnerabilidad o escenarios de extremo a extremo, y evitar mezclar métodos de forma incoherente dentro de una misma apreciación. 1. Analizar y evaluar frente a los criterios acordados de antemano para que la lista de prioridades sea reproducible, y luego elegir una opción de tratamiento : modificar, mantener, evitar o compartir. 1. Registrar el riesgo residual y obtener una aceptación explícita del responsable del riesgo designado, porque esa aprobación es lo que vincula la apreciación con la rendición de cuentas de la dirección según la ISO 27001. 1. Revisar la apreciación según una cadencia definida y tras un cambio significativo, para que la imagen del riesgo se mantenga actualizada en lugar de envejecer en silencio entre ciclos de certificación. --- ## ISO/IEC 27017 (ISO 27017) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27017 **Last reviewed:** 2026-06-24 ISO 27017 es la extensión de controles de seguridad en la nube para ISO 27001. Añade controles específicos para entornos cloud y clarifica el reparto de responsabilidad compartida entre proveedor y cliente. Si el alcance de vuestro ISMS incluye cargas de trabajo en hiperescaladores (AWS, Azure, GCP, OVH), los auditores preguntarán qué controles de ISO/IEC 27017 habéis mapeado. ## Lo que ISO/IEC 27017 aporta en la práctica ISO/IEC 27017 no es un esquema de certificación independiente. Es un código de buenas prácticas que se asienta sobre ISO/IEC 27002, la guía de implementación de los controles de ISO/IEC 27001. Donde 27002 describe un control de seguridad de la información genérico, 27017 añade orientación de implementación específica para la nube de ese mismo control y, en algunos puntos, introduce controles adicionales que solo cobran sentido cuando tus datos residen en una infraestructura que no posees. Por eso, cuando lo adoptas, no estás operando un SGSI paralelo. Estás ampliando el que ya certificas conforme a ISO 27001 para que hable el lenguaje de la nube. El valor práctico es que obliga a ambas partes de la relación en la nube a poner las cosas por escrito. La norma está deliberadamente estructurada de modo que cada pieza de orientación tiene una versión para el proveedor de servicios en la nube y otra para el cliente de servicios en la nube. Ese doble enfoque es la clave de todo. Un control como la gestión de accesos o el tratamiento de claves criptográficas significa algo distinto según seas el hyperscaler que opera la plataforma o el inquilino que despliega cargas de trabajo sobre ella, y 27017 hace explícita esa división en lugar de dejarla a la suposición. ## Responsabilidad compartida, hecha auditable Toda conversación sobre seguridad en la nube acaba aterrizando en la responsabilidad compartida: el proveedor protege la infraestructura, el cliente protege lo que pone sobre ella. El problema es que el límite se desplaza según el modelo de servicio. Con la infraestructura como servicio, el cliente es responsable del sistema operativo, los parches y la mayor parte de la configuración. Con el software como servicio, casi todo recae en el proveedor, y al cliente apenas le queda la identidad, los accesos y la gobernanza de los datos. ISO 27017 convierte ese diagrama difuso en algo que un auditor puede comprobar. - Pide al proveedor que documente qué responsabilidades de seguridad conserva y cuáles traspasa al cliente, de modo que no haya ninguna brecha silenciosa. - Pide al cliente que confirme que comprende y que realmente ha implementado su parte, en lugar de suponer que el proveedor se ocupa de ella. - Añade orientación específica para entornos multiinquilino, endurecimiento de máquinas virtuales, operaciones administrativas y la segregación de clientes que se ejecutan sobre hardware compartido. - Aborda la retirada y devolución de activos cuando finaliza un contrato, que es donde muchas salidas de la nube fallan. > **27017 es orientación, la certificación se obtiene a través de 27001** No existe un certificado ISO 27017 separado que se sostenga por sí solo. En la práctica, una organización certifica su SGSI conforme a ISO/IEC 27001 e incluye 27017 en el alcance, y luego evidencia qué controles de nube ha mapeado. Los auditores preguntarán qué controles de 27017 se aplican a tus cargas de trabajo en hyperscalers y cómo implementaste cada lado de la división. ## Dónde se sitúa frente a sus vecinas 27017 se confunde fácilmente con las normas que la rodean, así que conviene tener clara la familia. ISO/IEC 27001 es el sistema de gestión certificable. ISO/IEC 27002 es la orientación general de controles. ISO/IEC 27017 es la extensión de esa orientación a la seguridad en la nube. ISO/IEC 27018 es la hermana que se centra específicamente en la protección de la información de identificación personal en la nube pública, lo que importa cuando tus cargas de trabajo en la nube también transportan datos personales y respondes a obligaciones de privacidad además de las de seguridad. **ISO 27017 frente a sus vecinas** | Norma | Rol | Certificable por sí sola | | --- | --- | --- | | ISO/IEC 27001 | Requisitos del sistema de gestión de seguridad de la información | Sí | | ISO/IEC 27002 | Orientación general de implementación para controles de seguridad | No, orientación | | ISO/IEC 27017 | Controles de seguridad específicos de la nube y división proveedor/cliente | No, incluida en el alcance de 27001 | | ISO/IEC 27018 | Protección de datos personales en la nube pública | No, incluida en el alcance de 27001 | Para un profesional, el flujo de trabajo es coherente. Operas un SGSI ISO 27001, incorporas las cargas de trabajo en la nube a su alcance y usas 27017 para decidir qué controles de nube mapeas y cómo evidencias ambos lados de la línea de responsabilidad. Si esas cargas de trabajo también tratan datos personales, lo combinas con 27018. Ninguna de estas normas sustituye tu diligencia debida contractual sobre el proveedor; te dan una forma estructurada de demostrar que la realizaste. --- ## ISO/IEC 27018 (ISO 27018) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27018 **Last reviewed:** 2026-06-24 ISO 27018 es la extensión de controles de privacidad de ISO 27001 para proveedores de nube que actúan como encargados del tratamiento de información de identificación personal. Conecta ISO 27001 con las obligaciones del encargado bajo GDPR. La certificación la obtienen principalmente los grandes proveedores de nube y sus clientes la utilizan como insumo en la diligencia debida de proveedores. ## Qué añade la norma ISO/IEC 27018 por encima de ISO 27001 ISO/IEC 27018 es un código de buenas prácticas, no un sistema de gestión autónomo. Da por supuesto que usted ya opera un sistema de gestión de la seguridad de la información certificado conforme a ISO/IEC 27001, y le acopla una capa de privacidad sobre esa base. En concreto, se dirige a un único rol: un proveedor de servicios de nube pública que actúa como encargado del tratamiento de información de identificación personal (PII) por cuenta de sus clientes. La norma toma los controles genéricos de ISO/IEC 27002 y los reinterpreta para ese contexto de encargado, y después añade un conjunto de controles de privacidad específicos de la nube que ISO 27001 por sí sola no exige. La consecuencia práctica es que ISO 27018 no se certifica por sí sola. Un proveedor se certifica conforme a ISO 27001 con ISO 27018 como conjunto de controles aplicable dentro del alcance. Por eso la verá expresada como «certificado conforme a ISO 27001, auditado frente a ISO 27018» en lugar de como un certificado independiente. Los controles se refieren a cuestiones que un cliente de la nube no puede verificar fácilmente por sí mismo: si el proveedor utilizará la PII del cliente para su propia publicidad, si los subencargados se divulgan antes de ser contratados, cómo se tratan los datos al finalizar un contrato y qué ocurre cuando las autoridades solicitan acceso a los datos. ## Dónde se sitúa entre ISO 27001, ISO 27017 y el GDPR Tres referencias vecinas se confunden con ISO 27018, y las distinciones importan cuando se delimita una auditoría o se rellena un cuestionario de proveedor. ISO 27001 es el sistema de gestión que rige la seguridad de la información en general. ISO 27017 es el código de buenas prácticas de seguridad en la nube, más amplio que la privacidad y centrado en la seguridad de los servicios en la nube tanto para el proveedor como para el cliente. ISO 27018 es más estrecha que ambas: es privacidad, en la nube pública, únicamente para el rol de encargado del tratamiento. **ISO 27018 comparada con las normas vecinas** | Referencia | Alcance | Qué regula | | --- | --- | --- | | ISO/IEC 27001 | Gestión de la seguridad de la información | El SGSI certificable que las demás amplían | | ISO/IEC 27017 | Controles de seguridad en la nube | Seguridad de los servicios en la nube, proveedor y cliente | | ISO/IEC 27018 | Privacidad en la nube para encargados del tratamiento | Protección de la PII tratada por un encargado del tratamiento en la nube | | GDPR | Derecho de protección de datos de la UE | Obligaciones legales para responsables y encargados del tratamiento | ISO 27018 es un puente útil hacia las obligaciones del encargado del tratamiento bajo el GDPR porque operativiza ideas que el reglamento expresa en términos jurídicos: limitación de la finalidad, transparencia sobre la subcontratación, asistencia al responsable del tratamiento, y devolución o supresión de los datos. Pero no es un sustituto. Un certificado frente a ISO 27018 es prueba de buenas prácticas del encargado del tratamiento, no una constatación de cumplimiento legal. El GDPR asigna obligaciones mediante normas vinculantes y contratos entre responsable y encargado del tratamiento; una norma no puede hacer eso por usted. > **Es un insumo para la diligencia debida sobre proveedores, no una prueba de cumplimiento** ISO 27018 la poseen sobre todo los grandes hyperscalers y sus clientes la leen como uno de los insumos para la evaluación de proveedores. Trátela como prueba de que un proveedor se ha comprometido con prácticas de privacidad específicas, y después verifique en el contrato de tratamiento real los compromisos que le importan a usted. ## Qué hacen realmente los profesionales con ella Para la mayoría de las organizaciones, ISO 27018 es algo que se consume más que algo que se posee. Cuando selecciona un servicio en la nube y su evaluación de impacto relativa a la protección de datos o su proceso de riesgo de terceros pregunta «¿es de confianza este encargado del tratamiento?», la auditoría ISO 27018 del proveedor es uno de los artefactos que recopila, junto con las declaraciones de alcance de ISO 27001, los informes SOC y el acuerdo de tratamiento. - Confirme que el certificado está vigente y que el servicio en la nube que realmente utiliza queda dentro del alcance auditado, no solo el SGSI corporativo. - Léala junto con ISO 27001 e ISO 27017, ya que las tres están diseñadas para superponerse, y un proveedor que posee las tres ha cubierto la seguridad y la privacidad en la nube de forma más completa. - Asigne los controles de ISO 27018 a sus propias obligaciones bajo el GDPR en lugar de presuponer solapamiento, porque la norma respalda la relación de encargado del tratamiento pero no exonera al responsable del tratamiento de sus deberes legales. - Mantenga el contrato de tratamiento como documento vinculante. La norma señala intención; el acuerdo de tratamiento de datos es lo que usted hace cumplir. --- ## ISO/IEC 27034 (ISO 27034) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27034 **Last reviewed:** 2026-06-24 ISO 27034 es la norma de seguridad de aplicaciones. Consta de varias partes. Cubre el ciclo de vida seguro del software: requisitos, diseño, construcción, pruebas, despliegue y mantenimiento. Menos conocida que la 27001 porque vive dentro del SDLC, pero es la única norma ISO que habla el idioma de los equipos de desarrollo. Encaja de forma natural con las prácticas OWASP y SBOM. ## Qué se propone hacer la norma ISO/IEC 27034 ISO/IEC 27034 es el miembro dedicado a la seguridad de las aplicaciones dentro de la familia ISO/IEC 27000. Mientras que ISO/IEC 27001 rige el sistema de gestión que dirige todo su programa de seguridad de la información, ISO/IEC 27034 estrecha el enfoque a una sola cosa: construir y operar aplicaciones seguras a lo largo de todo el ciclo de vida del software, desde los requisitos y el diseño hasta la construcción, las pruebas, el despliegue y el mantenimiento. Es una norma de varias partes, lo que significa que las orientaciones se reparten en varios documentos en lugar de concentrarse en una única especificación certificable, y esa forma dice algo sobre su intención. Está pensada para informar cómo se realiza el desarrollo, no para entregar a un auditor una lista de verificación de casillas. La razón por la que permanece en segundo plano mientras ISO/IEC 27001 acapara la atención es estructural. La mayor parte de una organización habla de políticas, registros de riesgos y certificados; ISO/IEC 27034 habla a las personas que escriben y entregan el código. Vive dentro del ciclo de vida de desarrollo de software (SDLC), de modo que su público son desarrolladores, arquitectos e ingenieros de seguridad de aplicaciones más que el equipo de cumplimiento. Eso la convierte en la norma ISO más fluida en el lenguaje de los equipos de desarrollo, y en la que tiene más probabilidades de encajar limpiamente con cómo funciona realmente una organización de ingeniería en el día a día. ## La idea del control de seguridad de aplicaciones El concepto organizador en ISO/IEC 27034 es tratar la seguridad de las aplicaciones como un conjunto de controles verificables entretejidos en el ciclo de vida, en lugar de como una revisión de seguridad añadida al final. La norma plantea los requisitos de seguridad como algo que se deriva del contexto de la aplicación, de los datos que maneja y de las amenazas a las que se enfrenta, y que luego se arrastra a través del diseño, la implementación y la verificación, de modo que cada control tenga un punto definido donde se incorpora y un punto definido donde se comprueba. El efecto práctico es que la seguridad deja de ser una barrera en la entrega y se convierte en una propiedad mantenida en cada etapa, que es exactamente el giro que la práctica moderna de desarrollo seguro lleva años impulsando. Como la norma está orientada a procesos y modelada en torno al ciclo de vida, encaja cómodamente junto al material prescriptivo y práctico que los equipos ya usan. No sustituye al OWASP Application Security Verification Standard ni al OWASP Top 10; les da un marco de gobernanza del que colgar. También se combina de forma natural con la práctica del software bill of materials (SBOM), donde saber exactamente qué componentes se entregan en una aplicación es el control de la fase de mantenimiento que mantiene honesto el ciclo de vida tras la entrega. Usadas en conjunto, ISO/IEC 27034 aporta la estructura, y OWASP y el SBOM aportan las técnicas concretas y los inventarios. > **Un marco, no una lista de verificación** ISO/IEC 27034 resulta más útil como la estructura de ciclo de vida que organiza el desarrollo seguro. Recurra a OWASP ASVS, al OWASP Top 10 y a las herramientas de SBOM para las pruebas e inventarios concretos, y deje que ISO/IEC 27034 defina en qué punto del ciclo de vida pertenece cada uno. ## Dónde encaja junto a ISO/IEC 27001 La forma más clara de posicionar ISO/IEC 27034 es como el detalle de la capa de aplicación bajo un sistema de gestión ISO/IEC 27001. ISO/IEC 27001 certifica que usted opera un sistema de gestión de seguridad de la información con evaluación de riesgos y mejora continua, y su conjunto de controles incluye expectativas de desarrollo seguro enunciadas a un nivel alto. ISO/IEC 27034 es a donde acude para implementar realmente esas expectativas en ingeniería: cómo se capturan los requisitos seguros, cómo se verifican los controles, cómo viaja la seguridad a través del SDLC. Un equipo certificado en ISO/IEC 27001 puede usar ISO/IEC 27034 para dar sustancia a sus controles de desarrollo seguro, y una organización de desarrollo puede usar ISO/IEC 27034 para asegurarse de que el código que entrega resistiría ante ese sistema de gestión más amplio. En la práctica, las organizaciones rara vez se certifican frente a ISO/IEC 27034 como lo hacen frente a ISO/IEC 27001. La adoptan como orientación, trasladan la estructura de ciclo de vida a su propio estándar de desarrollo seguro y la referencian cuando necesitan una base con autoridad para justificar por qué la seguridad de las aplicaciones se gestiona de la manera en que se gestiona. Para un equipo pequeño, el valor es el mismo que para una gran empresa: una manera reconocida y neutral respecto al proveedor de describir un SDLC seguro que auditores, clientes y desarrolladores aceptan por igual. --- ## ISO/IEC 27037 (ISO 27037) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27037 **Last reviewed:** 2026-06-24 ISO 27037 es la norma de informática forense para identificar, recopilar, adquirir y preservar evidencia digital. Es la referencia que utiliza un equipo forense interno, un CERT o un consultor de apoyo en litigios para mantener la cadena de custodia íntegra. Trátela como el protocolo con el que auditores y abogados compararán sus actuaciones tras un incidente. ## Qué regula la norma ISO/IEC 27037 La ISO/IEC 27037 es la directriz internacional para la primera fase, la más frágil, de cualquier investigación digital: hacerse con la evidencia sin destruirla. Se enmarca dentro de la familia más amplia ISO/IEC 27000, junto a la ISO/IEC 27001, pero mientras la 27001 indica cómo gestionar un sistema de gestión, la 27037 indica a sus intervinientes exactamente cómo manipular un servidor en funcionamiento, un portátil incautado, un teléfono o una cuenta en la nube para que lo capturado pueda después resistir el escrutinio. Cubre cuatro actividades en secuencia: identificar la evidencia digital potencial, recolectar los dispositivos físicos, adquirir los datos de ellos y preservar tanto los dispositivos como las copias hasta la entrega. La norma introduce dos roles a los que los profesionales recurren constantemente. El Digital Evidence First Responder (DEFR) es la persona presente en la escena que decide qué incautar y cómo. El Digital Evidence Specialist (DES) posee la competencia técnica más profunda para tratar los casos delicados, como los sistemas en vivo, los volúmenes cifrados o el hardware inusual. Se espera de ambos que documenten cada decisión, porque el valor de la evidencia digital descansa menos en los bytes en sí mismos que en si puede probar que no fueron alterados. ## La cadena de custodia y los principios que la sustentan La 27037 se apoya en un puñado de principios que reaparecen en todo método forense creíble. La evidencia adquirida debe ser pertinente, fiable y suficiente. Las acciones realizadas sobre el original deben mantenerse en el mínimo necesario y estar plenamente justificadas. Cualquier persona competente debe poder repetir el proceso y llegar al mismo resultado, razón por la cual las herramientas de imagen, los bloqueadores de escritura y los hashes de verificación importan tanto. El hilo que lo une todo es la cadena de custodia: un registro continuo y documentado de quién tuvo la evidencia, qué hizo con ella y cuándo, desde el momento de la recolección hasta su presentación. - Identificación: reconocer lo que podría constituir evidencia, desde discos y teléfonos hasta memoria volátil y capturas de red. - Recolección: retirar los dispositivos de la escena, con el orden de volatilidad decidiendo qué se captura primero. - Adquisición: producir una copia verificable, normalmente una imagen forense validada mediante un hash criptográfico. - Preservación: proteger el original y las copias frente a toda alteración, pérdida o contaminación. > **Una directriz, no una certificación** No se certifica a una organización conforme a la ISO/IEC 27037 como sí se hace conforme a la ISO/IEC 27001. Es un método que sigue su equipo forense, su CERT o su consultor de apoyo al litigio, y el referente con el que los auditores y abogados medirán su tratamiento tras un incidente. Normas relacionadas la amplían: la ISO/IEC 27041 sobre el aseguramiento, la 27042 sobre el análisis y la interpretación, y la 27043 sobre el conjunto del proceso de investigación. ## Dónde encaja en la respuesta a incidentes y en la familia más amplia En la práctica, la 27037 es el puente entre detectar un incidente y poder hacer algo útil con los artefactos después. Un SOC interno que toma una imagen de disco de la manera equivocada, o que borra la memoria volátil al reiniciar un host comprometido, puede detectar a un atacante a la perfección y aun así acabar con una evidencia en la que ningún tribunal o regulador confiará. Por eso se lee junto a las orientaciones de gestión de incidentes de la ISO/IEC 27035 y los controles del Anexo A de la ISO/IEC 27001. La disciplina es la misma tanto si el objetivo es una acción penal, un conflicto laboral, una reclamación de seguro o, sencillamente, un informe interno que resista la impugnación. Para los profesionales, la conclusión es procedimental, no teórica. Decida de antemano quiénes son sus DEFR y DES, dóteles de herramientas validadas, redacte el formulario de cadena de custodia antes de necesitarlo y ensaye el orden de volatilidad para que nadie reinicie la única máquina que importaba. Cuando una investigación sale mal, casi nunca es el análisis lo que falla. Es la primera hora, justamente la hora sobre la que está escrita la 27037. --- ## ISO/IEC 27701 (ISO 27701) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-27701 **Last reviewed:** 2026-06-24 ISO 27701 es la extensión de gestión de información de privacidad sobre ISO 27001. Añade obligaciones de responsable y encargado del tratamiento sobre el SGSI. Útil para organizaciones que desean un único sistema de gestión certificable que cubra tanto seguridad como privacidad. Se corresponde con el GDPR, pero no «sustituye» el trabajo de cumplimiento del GDPR. ## Una extensión, no una norma autónoma ISO/IEC 27701 no se sostiene por sí sola. Está concebida como una extensión de ISO/IEC 27001 e ISO/IEC 27002, lo que significa que no puede certificarse en ella sin disponer previamente de un sistema de gestión de la seguridad de la información (SGSI) en funcionamiento. La norma toma los controles de seguridad que ya opera y superpone requisitos y orientaciones específicos de privacidad, convirtiendo el SGSI en un Sistema de Gestión de Información de Privacidad (PIMS). Para una organización que ya opera ISO 27001, este es un paso eficiente: reutiliza el mismo gobierno, la misma metodología de riesgo, el mismo ciclo de auditoría, y amplía el alcance para cubrir el tratamiento de información de identificación personal (PII). Esa elección arquitectónica es la cuestión central. En lugar de gestionar la privacidad como un programa separado con sus propios comités y sus propias evidencias, ISO 27701 le permite certificar un único sistema de gestión que cubre tanto la seguridad como la privacidad. La Declaración de Aplicabilidad se amplía, la evaluación de riesgos considera ahora el riesgo de privacidad para las personas y no solo el riesgo para la organización, y el mismo organismo de certificación audita el conjunto en un solo encargo. ## Obligaciones del responsable y del encargado del tratamiento ISO 27701 reparte sus requisitos adicionales según la misma línea que traza la legislación de protección de datos: entre la organización que actúa como responsable del tratamiento (decidiendo por qué y cómo se trata la PII) y la organización que actúa como encargado del tratamiento (tratando PII por cuenta de un tercero). Muchas organizaciones son ambas a la vez, según el conjunto de datos, por lo que la norma le ofrece dos conjuntos de orientaciones y le pide aplicar el que corresponda a cada actividad de tratamiento. - Los temas del lado del responsable del tratamiento incluyen la base de licitud y la finalidad, el consentimiento y la elección, la transparencia hacia las personas, la gestión de las solicitudes de los interesados, los registros de tratamiento, y las obligaciones cuando comparte PII con terceros. - Los temas del lado del encargado del tratamiento incluyen actuar únicamente conforme a instrucciones documentadas, asistir al responsable en sus obligaciones, gestionar a los subencargados, y devolver o suprimir la PII al término de un contrato. En la práctica, esto es lo que un equipo de privacidad ya hace bajo los regímenes modernos de protección de datos, pero ISO 27701 lo organiza en controles auditables con evidencia documentada, que es precisamente lo que convierte una postura de privacidad en algo que un tercero puede verificar. ## Dónde se sitúa junto al GDPR La lectura errónea más común es que la certificación ISO 27701 le hace cumplir con el GDPR. No lo hace, y tiene cuidado de no afirmarlo. El GDPR es una ley e ISO 27701 es una norma de sistema de gestión voluntaria. Lo que 27701 le aporta es un marco estructurado y certificable cuyos controles se corresponden estrechamente con los principios de protección de datos, por lo que constituye una prueba sólida de responsabilidad proactiva (accountability) y una buena columna vertebral operativa. Pero el cumplimiento de un régimen legal específico sigue requiriendo su propio análisis jurídico, sus registros, y su gestión demostrable de los derechos individuales bajo esa ley. > **Un certificado es una prueba, no una defensa** Un certificado ISO 27701 muestra que un auditor verificó su PIMS frente a la norma. Los reguladores pueden tratarlo como una señal creíble de responsabilidad proactiva, pero no sustituye el cumplimiento de las obligaciones reales del GDPR ni de cualquier otra ley de privacidad aplicable. Considérelo como la capa de gestión que hace repetible el cumplimiento legal, no como el cumplimiento en sí. **ISO 27701 junto al GDPR** | Dimensión | ISO/IEC 27701 | GDPR | | --- | --- | --- | | Naturaleza | Norma de sistema de gestión voluntaria | Ley vinculante de la UE | | Qué produce | Un PIMS certificable | Obligaciones legales y derechos individuales | | Construida sobre | ISO 27001 / ISO 27002 | Principios de protección de datos | | Verificada por | Organismo de certificación acreditado | Autoridades de control y tribunales | | Relación | Se corresponde con el cumplimiento y lo respalda | La obligación que 27701 le ayuda a cumplir | La forma limpia de operarlo es anclar la privacidad en el mismo SGSI que utiliza para la seguridad, certificar el sistema combinado a ISO 27001 más ISO 27701, y mantener a su delegado de protección de datos y a su equipo jurídico como propietarios de la ley misma. La norma se encarga de la disciplina operativa; ellos se encargan de la interpretación. --- ## ISO/IEC 42001 (ISO 42001) **URL:** https://cyberacademy.net/es/resources/encyclopedia/iso-42001 **Last reviewed:** 2026-06-24 ISO 42001 es el primer estándar internacional para sistemas de gestión de la IA, publicado a finales de 2023. El equivalente AIMS de lo que es el ISMS en ISO 27001. Diseñado para organizaciones que necesitan gobernar el diseño, despliegue y operación de la IA: riesgo, responsabilidad, transparencia, mejora continua. Se alinea directamente con las obligaciones de alto riesgo del AI Act. ## Qué rige realmente la norma ISO/IEC 42001 ISO/IEC 42001 es la primera norma de sistema de gestión certificable dedicada a la inteligencia artificial. No le indica qué modelo entrenar ni cómo ajustar una red neuronal. En cambio, define un sistema de gestión de la IA (AIMS): las políticas, funciones, procesos y controles que una organización implanta para desarrollar, proporcionar o utilizar la IA de forma responsable. Si ya conoce ISO 27001, el modelo mental se traslada de manera directa. Allí donde el SGSI protege la información, el AIMS gobierna el ciclo de vida de los sistemas de IA, desde la finalidad prevista y la obtención de datos hasta el despliegue, la supervisión y el desmantelamiento. La norma sigue la misma estructura de alto nivel (High-Level Structure) que ISO 27001 e ISO 9001: contexto de la organización, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora. Esa columna vertebral compartida es deliberada. Le permite acoplar el AIMS a un sistema de gestión integrado existente en lugar de operar un silo de gobernanza paralelo. La sustancia específica de la IA reside en los anexos, que establecen controles de referencia y orientación para la implementación que abarcan cuestiones como la rendición de cuentas, la calidad de los datos, la transparencia hacia los usuarios, la supervisión humana y la evaluación de impacto. ## En qué se diferencia de ISO 27001 y de una política de riesgos genérica Los profesionales que provienen de la seguridad suelen suponer que un SGSI ya cubre la IA. No es así. ISO 27001 se construye en torno a la confidencialidad, la integridad y la disponibilidad de la información. ISO 42001 añade preocupaciones que no tienen cabida natural en un marco de seguridad: si un sistema se comporta de forma justa, si sus salidas son explicables, si un humano puede intervenir de manera significativa y si la IA se utiliza únicamente para su finalidad declarada. El razonamiento sobre el riesgo también es más amplio. Una apreciación del riesgo según 42001 sopesa los impactos sobre las personas y la sociedad, no solo sobre la organización, razón por la cual una evaluación de impacto de la IA constituye una actividad diferenciada y nombrada dentro de la norma. > **AIMS y SGSI son complementarios, no redundantes** Las organizaciones que poseen ISO 27001 normalmente amplían su gobernanza existente en lugar de reconstruirla. Los controles de referencia del Anexo A de ISO 42001 se sitúan junto a los controles de seguridad, no dentro de ellos, y ambas certificaciones pueden compartir auditorías, compromiso de la dirección y ciclos de mejora. ## Por qué importa para el Reglamento Europeo de IA (EU AI Act) ISO 42001 se alinea con precisión con las expectativas del AI Act para los sistemas de alto riesgo. El reglamento exige a los proveedores de IA de alto riesgo que operen un sistema de gestión de riesgos, mantengan una gobernanza de datos, conserven documentación técnica, garanticen la supervisión humana y realicen una vigilancia poscomercialización. Esas son precisamente las disciplinas que un AIMS institucionaliza. Un sistema de gestión certificado no sustituye la conformidad jurídica, y la certificación por sí sola no hace que un sistema sea conforme. Lo que aporta es una estructura auditable y repetible que demuestra la diligencia debida y convierte el cumplimiento de las obligaciones del AI Act en una cuestión de operar un sistema existente en lugar de improvisar bajo la presión de los plazos. ## Cómo es la implementación en la práctica Los equipos que adoptan 42001 suelen recorrer una secuencia reconocible: 1. Definir el alcance: qué sistemas de IA, usados por quién, para qué finalidad prevista y dónde se sitúa la organización en la cadena de suministro (desarrollador, proveedor, implementador). 1. Realizar la apreciación del riesgo de la IA y la evaluación de impacto, identificando los riesgos para las personas y la organización y seleccionando controles para tratarlos. 1. Asignar una responsabilidad clara para que un propietario nombrado responda de cada sistema de IA a lo largo de su ciclo de vida. 1. Establecer una gobernanza de datos, mecanismos de transparencia y supervisión humana adecuados al nivel de riesgo. 1. Supervisar los sistemas en operación, capturar incidentes y comentarios, y reincorporarlos a la mejora continua. La certificación es opcional, pero cada vez más solicitada por compradores corporativos y equipos de aprovisionamiento que desean garantía de un tercero de que un proveedor de IA gobierna sus sistemas en lugar de entregarlos a ciegas. --- ## Information Systems Audit and Control Association (ISACA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/isaca **Last reviewed:** 2026-06-24 ISACA es la asociación global de profesionales de auditoría TI, seguridad, riesgo y gobierno. Fundada en 1969, con sede en Schaumburg (Illinois) y más de 165.000 miembros en 188 países. Otorga las certificaciones CISA, CISM, CRISC, CGEIT, CDPSE, AAIA, CCOA. Publica COBIT. Cyber Academy es ISACA Accredited Premium Partner. ## Qué es realmente ISACA ISACA nació en 1969 como la Information Systems Audit and Control Association, un grupo de auditores de TI que necesitaban un cuerpo de conocimiento común y una forma de certificar mutuamente sus competencias. El nombre completo es hoy en gran medida histórico; la organización opera como ISACA y atiende a profesionales de auditoría de TI, seguridad, riesgo, gobernanza y privacidad en más de 180 países. Lo que importa en la práctica es que ISACA no es un regulador ni un organismo de normalización en el sentido de ISO. No redacta leyes y no puede certificar a una empresa. Certifica a personas y publica marcos en los que se apoya el resto de la profesión. Esa distinción confunde a los recién llegados. No se puede llegar a ser una empresa «certificada por ISACA» del mismo modo que se certifica un sistema de gestión ISO 27001. Las credenciales de ISACA recaen en los individuos. Un auditor obtiene la CISA, un responsable de seguridad obtiene la CISM, un profesional del riesgo obtiene la CRISC. El valor de la credencial proviene del rigor del examen, del requisito documentado de experiencia laboral, del código de ética profesional y de la formación profesional continua que la mantiene vigente. Los empleadores y los comités de auditoría las consideran prueba de que la persona ha sido evaluada de forma independiente frente a una práctica definida. ## La familia de credenciales y lo que cada una señala Las certificaciones de ISACA están deliberadamente vinculadas a un rol específico en lugar de constituir una única cualificación general. Cada una se corresponde con una función laboral distinta, motivo por el cual los profesionales suelen tener más de una a medida que su carrera pasa de ejecutar el trabajo a gobernarlo. **Certificaciones de ISACA por rol profesional** | Credencial | Público | Enfoque | | --- | --- | --- | | CISA | Auditores de SI | Auditoría, control y aseguramiento de los sistemas de información | | CISM | Responsables de seguridad | Gobernanza y gestión de un programa de seguridad de la información | | CRISC | Profesionales del riesgo | Identificación y respuesta al riesgo de TI y empresarial | | CGEIT | Líderes de gobernanza | Gobernanza de la TI empresarial a nivel de consejo de administración | | CDPSE | Ingenieros de privacidad | Privacidad desde el diseño en la pila tecnológica | | AAIA | Auditores de IA | Auditoría de sistemas y controles de inteligencia artificial | | CCOA | Operaciones cibernéticas | Operaciones y defensa prácticas de ciberseguridad | > **ISACA certifica personas, ISO certifica sistemas** Cuando alguien dice que una firma está «acreditada por ISACA», normalmente quiere decir que su personal posee credenciales de ISACA o que es un socio de formación reconocido por ISACA. Una empresa en sí no está certificada frente a una norma de ISACA. Para eso existen ISO 27001 y normas certificables similares. ## COBIT y el lugar de ISACA en el panorama de las normas Además de certificar a individuos, ISACA publica COBIT, el marco para la gobernanza y la gestión de la TI empresarial. COBIT es donde ISACA más se acerca a actuar como un organismo de normalización, pero sigue siendo un marco que se adopta y adapta en lugar de una norma frente a la que uno se certifica. Los auditores recurren a COBIT cuando una norma de seguridad de la información por sí sola resulta demasiado estrecha, porque abarca cómo se orienta la TI en su conjunto hacia los objetivos de la empresa. Por eso ISACA, NIST e ISO suelen mencionarse juntos: NIST aporta catálogos de controles y resultados, ISO aporta normas de gestión certificables, e ISACA aporta la óptica de la auditoría y la gobernanza, además de las personas cualificadas para aplicarla. Para una organización de formación, el programa de socios de ISACA importa porque la preparación del examen debe seguir un plan de estudios acreditado para tener peso. Cyber Academy es un ISACA Accredited Premium Partner, que es el reconocimiento que ISACA otorga a los proveedores de formación que cumplen su nivel de calidad para impartir la preparación oficial de credenciales. Esa acreditación se refiere al proveedor, no sustituye a que el individuo apruebe el examen de ISACA y cumpla el requisito de experiencia. --- ## Lead Auditor **URL:** https://cyberacademy.net/es/resources/encyclopedia/lead-auditor **Last reviewed:** 2026-06-24 Lead Auditor es la credencial PECB para profesionales que planifican y lideran auditorías de tercera parte o internas de un sistema de gestión. Curso de cinco días basado en ISO 19011. Punto de entrada para convertirse en auditor de organismo de certificación acreditado. Enfoque distinto al del Lead Implementer: evidencias, muestreo, elaboración de informes y técnica de entrevista. ## Qué certifica la credencial de Lead Auditor Lead Auditor es la certificación de PECB para profesionales capaces de planificar, dirigir y reportar la auditoría de un sistema de gestión, ya se trate de una auditoría de certificación por tercera parte, una auditoría a proveedores o una auditoría interna de envergadura. El curso se desarrolla a lo largo de cinco días y se basa directamente en ISO 19011, la norma de referencia para auditar sistemas de gestión. Lo que usted certifica al terminar no es que comprenda una norma como ISO 27001 en abstracto, sino que puede dirigir un equipo de auditoría frente a ella: definir el alcance del encargo, muestrear evidencia, realizar entrevistas, redactar hallazgos que resistan la objeción y llevar la auditoría a una conclusión defendible. La credencial existe por una razón profesional concreta. Es el punto de entrada reconocido para convertirse en auditor acreditado de un organismo de certificación, la persona que acude en nombre de un organismo de certificación para decidir si una organización obtiene o conserva su certificado. Los organismos de certificación operan bajo ISO/IEC 17021-1, y necesitan auditores que hayan demostrado la competencia que describe ISO 19011. Lead Auditor es la manera de señalar que usted posee esa competencia y las capacidades de liderazgo para dirigir el equipo, no solo participar en él. ## Una mentalidad distinta a la del Lead Implementer La confusión más habitual es tratar Lead Auditor y Lead Implementer como dos variantes de la misma cualificación. Son posturas opuestas. El implementador construye el sistema de gestión: redacta las políticas, diseña los controles, realiza la evaluación de riesgos y prepara a la organización para la certificación. El auditor juzga de forma independiente si lo que se construyó realmente existe y funciona. La misma persona no debería hacer ambas cosas sobre el mismo sistema, porque el implementador no puede garantizar de forma creíble su propio trabajo. Esa independencia es la razón misma de que exista el rol de auditor. En la práctica, la mentalidad del auditor se centra en la evidencia, no en el consejo. Donde el implementador se pregunta cómo hacer eficaz un control, el auditor se pregunta qué prueba demuestra que el control opera tal como se describe, cuán representativa es la muestra y si el hallazgo se sostiene si el auditado lo rebate. El curso Lead Auditor dedica la mayor parte de su energía a esas habilidades y no a la norma en sí: - Muestreo: elegir evidencia que represente con equidad el conjunto, y no las partes que casualmente parecen favorables. - Técnica de entrevista: extraer cómo se realiza realmente el trabajo sin inducir al testigo. - Hallazgos y reporte: clasificar no conformidades, redactarlas de forma objetiva y trazable, y alcanzar una conclusión. - Liderazgo de auditoría: gestionar un equipo de auditoría, las reuniones de apertura y cierre, y la relación con el auditado. > **La etiqueta de la norma viaja con el sistema** Un curso de Lead Auditor siempre está anclado a una norma específica, por ejemplo ISO 27001 Lead Auditor o ISO 9001 Lead Auditor. El método de auditoría proviene de ISO 19011 y es común a todos ellos, pero usted se forma y se certifica frente a los requisitos del sistema de gestión que pretende auditar. ## Dónde se sitúa el Lead Auditor entre las credenciales vecinas El Lead Auditor se entiende mejor junto a las credenciales con las que los profesionales lo comparan. Dentro del mundo PECB e ISO, hace pareja con Lead Implementer como su contraparte de aseguramiento. Frente a ISACA, la credencial CISA también certifica competencia en auditoría, pero es una cualificación amplia de auditoría de TI ligada a los dominios de ISACA, y no una credencial para auditar un sistema de gestión concreto sobre ISO 19011. **Lead Auditor comparado con credenciales vecinas** | Credencial | Postura | Qué certifica | | --- | --- | --- | | Lead Auditor | Aseguramiento independiente | Planificar y dirigir la auditoría de un sistema de gestión sobre ISO 19011 | | Lead Implementer | Construir y operar | Diseñar y operar un sistema de gestión orientado a la certificación | | CISA | Aseguramiento de auditoría de TI | Auditoría amplia de sistemas de información a través de los dominios de ISACA | Elegir entre ellos depende del trabajo que pretenda realizar. Si su futuro pasa por realizar auditorías de certificación o a proveedores, o por dirigir un programa de auditoría interna riguroso, Lead Auditor es la vía directa. Si su labor es poner en marcha y mejorar el propio sistema de gestión, Lead Implementer encaja mejor. Muchos profesionales con experiencia poseen ambas, porque comprender cómo se construye un sistema le convierte en un auditor más perspicaz, y comprender cómo será auditado le convierte en un mejor implementador. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/es/resources/encyclopedia/lead-ethical-hacker **Last reviewed:** 2026-06-24 Lead Ethical Hacker es la credencial certificada por PECB para profesionales de seguridad ofensiva. Cubre metodología, alcance, reconocimiento, explotación, elaboración de informes y ética. Complemento de acreditación para credenciales prácticas como OSCP y CRTO. Se combina con Lead Penetration Testing Professional para el liderazgo de compromisos. Lead Ethical Hacker es la certificación PECB dirigida a los profesionales de la seguridad ofensiva: las personas autorizadas a atacar un sistema para que una organización descubra dónde fallaría realmente. Se estructura en torno al ciclo de vida completo de un encargo, en lugar de a una sola técnica. Se espera que un titular delimite un encargo, recopile el reconocimiento, encuentre y explote las debilidades y, después, convierta ese trabajo en un informe sobre el que los responsables de la toma de decisiones puedan actuar, todo ello dentro de un marco ético y legal claro. Mientras que muchas certificaciones ofensivas demuestran que sabes comprometer una máquina en laboratorio, Lead Ethical Hacker se posiciona como el complemento de acreditación de esa capacidad práctica: una señal neutral respecto a los fabricantes y alineada con ISO, que acredita que sabes ejecutar un encargo de hacking ético de principio a fin, no solo explotarlo. ## Qué cubre la certificación La certificación sigue el arco de un encargo real, de modo que las competencias que valida se corresponden con las fases por las que un evaluador transita en una evaluación. - Delimitación y reglas de compromiso: definir objetivos, límites, autorización y lo que queda explícitamente fuera del alcance antes de enviar un solo paquete. - Reconocimiento y enumeración: construir una imagen de la superficie de ataque a partir de fuentes abiertas y sondeo activo. - Explotación: utilizar las debilidades identificadas para demostrar un impacto concreto y respaldado por pruebas, en lugar de un riesgo teórico. - Postexplotación y pivotaje: mostrar hasta dónde podría llegar razonablemente un atacante una vez establecido un punto de apoyo. - Elaboración del informe: traducir los hallazgos en orientación de remediación priorizada, reproducible y comprensible para el negocio. - Ética y derecho: permanecer dentro del mandato, gestionar los hallazgos sensibles de forma responsable y proteger al cliente durante todo el proceso. > **Una acreditación, no un sustituto de los laboratorios prácticos** Lead Ethical Hacker es la capa de metodología y criterio. Se combina de forma natural con certificaciones prácticas evaluadas en laboratorio como OSCP o CRTO. Considérala una prueba de que sabes dirigir y documentar un encargo conforme a un estándar reconocido, junto con certificaciones prácticas que acreditan la destreza pura de explotación. ## En qué se diferencia de conceptos vecinos El hacking ético y la prueba de penetración se solapan en gran medida y los términos se emplean a menudo de forma intercambiable, pero no son idénticos. Una prueba de penetración es un ejercicio delimitado y acotado en el tiempo, con un objetivo definido y un informe. El hacking ético es la disciplina y la mentalidad más amplias de atacar sistemas con permiso para mejorar su seguridad, de la que una prueba de penetración estructurada es una de sus expresiones. También se distingue de un encargo de red team, que es una simulación más larga y orientada a objetivos, que pone a prueba tanto la detección y la respuesta como los propios controles, y del escaneo de vulnerabilidades automatizado, que prioriza la amplitud frente a la explotación manual y el razonamiento que aporta un evaluador. **Lead Ethical Hacker entre las certificaciones de seguridad ofensiva** | Certificación | Centro de gravedad | Léase ante todo como | | --- | --- | --- | | Lead Ethical Hacker | Metodología del encargo, delimitación, elaboración del informe, ética | Acreditación de que sabes ejecutar un encargo | | OSCP / CRTO | Explotación práctica en laboratorios evaluados | Prueba de destreza práctica de ataque | | Lead Penetration Testing Professional | Dirigir y gestionar un programa de pruebas | Complemento orientado al liderazgo del encargo | Como señala la definición breve, la certificación se combina con Lead Penetration Testing Professional para quienes avanzan hacia el liderazgo de encargos: una se centra en el acto del hacking ético, la otra en hacerse cargo del proceso de pruebas en toda una organización. ## A quién va dirigida Encaja con profesionales que ya realizan o se orientan hacia el trabajo ofensivo: evaluadores de penetración, miembros de red team y consultores de seguridad que quieren una certificación reconocida y alineada con estándares que refleje cómo ejecutan sus encargos, no solo que sepan encontrar un fallo. Dado que las certificaciones PECB son neutrales respecto a los fabricantes y están alineadas con ISO, su valor reside en una señal de competencia estructurada y legible a escala internacional. Como siempre, los empleadores valoran la capacidad demostrada, por lo que el perfil más sólido combina esta acreditación con certificaciones prácticas y un historial de pruebas reales y autorizadas. --- ## Lead Implementer **URL:** https://cyberacademy.net/es/resources/encyclopedia/lead-implementer **Last reviewed:** 2026-06-24 Lead Implementer es la credencial PECB para profesionales que pueden planificar, implantar y operar un sistema de gestión basado en una norma ISO específica (con mayor frecuencia ISO/IEC 27001, ISO/IEC 42001 o ISO 22301). Curso de cinco días, examen y certificado. Representa la vertiente de implantación dentro de la disciplina ISO; complementa al Lead Auditor en el ámbito de la auditoría. ## Qué hace realmente un Lead Implementer Un Lead Implementer es la persona que toma una norma ISO de sistema de gestión y la convierte en algo que una organización real opera cada día. Donde la norma dice qué debe existir, el Lead Implementer decide cómo llegar hasta ahí: definir el alcance del sistema, asegurar el compromiso de la dirección, llevar a cabo la apreciación del riesgo, seleccionar y redactar los controles y procedimientos, formar a las personas que los operarán, y dirigir todo el esfuerzo hasta el punto en que un organismo de certificación pueda auditarlo. La credencial en sí, otorgada por PECB tras un curso de cinco días y un examen, certifica que sabes liderar este trabajo en lugar de solo describirlo. En el día a día, el rol es en parte director de proyecto, en parte experto en la materia, en parte diplomático interno. La mayoría de las implementaciones ISO no fracasan por los controles técnicos sino por el trabajo que las rodea: lograr que la alta dirección patrocine el proyecto, acordar el alcance, definir los roles, y arraigar la información documentada para que sobreviva a la primera auditoría y siga viva después. PECB estructura su formación Lead Implementer en torno a un método de implementación por fases, de modo que los candidatos salen con una secuencia repetible que seguir en lugar de un montón de cláusulas que memorizar. ## Lead Implementer frente a Lead Auditor Las dos credenciales emblemáticas de PECB describen las dos caras de la disciplina ISO. Un Lead Implementer construye y opera el sistema de gestión desde dentro de la organización. Un Lead Auditor evalúa un sistema de gestión frente a la norma, por lo general desde fuera, y decide si es conforme. Comparten la misma norma de base y gran parte del mismo conocimiento, pero la mentalidad es distinta: el implementer es responsable de hacer que el sistema funcione, el auditor es responsable de juzgarlo con imparcialidad. **Lead Implementer comparado con Lead Auditor** | Aspecto | Lead Implementer | Lead Auditor | | --- | --- | --- | | Rol principal | Construir, desplegar y operar el sistema de gestión | Evaluar la conformidad frente a la norma | | Punto de vista | Dentro de la organización | Independiente, a menudo tercera parte | | Entregable central | Un sistema de gestión operativo y certificable | Un informe de auditoría y un juicio de conformidad | | Referencia para el método | Un enfoque de implementación por fases | Directrices de auditoría ISO 19011 | En la práctica las certificaciones se complementan y muchos profesionales poseen ambas. Comprender cómo un auditor pondrá a prueba el sistema te convierte en un implementer más perspicaz, y haber construido tú mismo un sistema te convierte en un auditor más creíble. Quienes desean un dominio más sólido del lado de la auditoría suelen combinar Lead Implementer con la vía Lead Auditor. > **Certifica a la persona, no a la organización** Lead Implementer es una credencial personal. Acredita que sabes construir un sistema de gestión conforme a una norma ISO determinada. La organización se certifica por separado mediante un organismo de certificación acreditado frente a la norma en sí, como ISO 27001 para la seguridad de la información. ## Qué norma, y dónde encaja Lead Implementer no está ligado a una sola norma. La misma competencia se ofrece para varias normas ISO de sistema de gestión, con mayor frecuencia ISO 27001 para la seguridad de la información, ISO 42001 para los sistemas de gestión de IA, e ISO 22301 para la continuidad del negocio, entre otras. Como estas normas comparten la estructura común de alto nivel que ISO utiliza en sus sistemas de gestión, el método de implementación se transfiere bien: alcance, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora reaparecen en cada una. Una vez que has liderado una implementación, la siguiente norma es en su mayor parte nuevo contenido de dominio superpuesto sobre un esqueleto familiar. Para los profesionales que deciden por dónde empezar, el planteamiento honesto es este. Si tu trabajo gira en torno a la seguridad de la información, ISO 27001 Lead Implementer es el ancla natural y la que se menciona con más frecuencia en las ofertas de empleo. Si tu organización avanza hacia una IA gobernada, ISO 42001 Lead Implementer es el equivalente emergente. En cualquier caso, sales capaz de dirigir el proyecto, no solo de presentarte al examen, que es lo que el rol exige una vez que vuelves a tu escritorio frente a un plazo de certificación real. --- ## MITRE ATT&CK **URL:** https://cyberacademy.net/es/resources/encyclopedia/mitre-attack **Last reviewed:** 2026-06-24 MITRE ATT&CK es la base de conocimiento abierta de tácticas, técnicas y procedimientos (TTPs) de atacantes observados en entornos reales. Vocabulario estándar para la defensa basada en inteligencia de amenazas: reglas de detección, escenarios de red team, formación de analistas SOC. Se actualiza de forma continua y es de uso gratuito. Si las reglas de su SIEM no referencian los identificadores de técnicas de ATT&CK, está trabajando más de lo necesario. ## Un lenguaje común para describir cómo se comportan los atacantes MITRE ATT&CK reorienta la inteligencia de amenazas en torno al comportamiento en lugar de los indicadores. En vez de catalogar las direcciones IP o los hashes de archivos vistos en una sola campaña, que cambian constantemente, cataloga lo que los adversarios realmente hacen una vez dentro de un entorno: cómo obtienen el acceso inicial, escalan privilegios, se mueven lateralmente, evaden las defensas y exfiltran datos. Cada uno de esos comportamientos se captura como una técnica con un identificador estable, y las técnicas se agrupan bajo tácticas que describen el objetivo del atacante en cada paso. El resultado es un mapa estructurado y basado en evidencia del manual de jugadas adversario, extraído de intrusiones reales observadas en lugar de la teoría. El marco está organizado como una matriz. Las columnas son las tácticas, el porqué detrás de un paso, y las celdas debajo de cada columna son las técnicas y subtécnicas, el cómo. Matrices separadas cubren los entornos Enterprise, móviles y los sistemas de control industrial, porque el comportamiento del adversario difiere según esos terrenos. Como los identificadores de técnicas son estables y públicos, se convierten en una referencia común que un analista de inteligencia de amenazas, un ingeniero de SOC que escribe detecciones y un miembro de un red team que planifica un ejercicio pueden citar todos sin ambigüedad. Ese vocabulario compartido es el superpoder silencioso de ATT&CK: permite que equipos que nunca se hablan describan el mismo ataque de la misma manera. ## Tácticas, técnicas y procedimientos El modelo TTP está en el corazón de ATT&CK y conviene mantener los tres niveles diferenciados. Las tácticas son los objetivos del adversario, las metas amplias como conseguir un punto de apoyo o mantener la persistencia. Las técnicas son los métodos generales usados para lograr una táctica, y muchas técnicas se desglosan a su vez en subtécnicas que describen una variante más específica. Los procedimientos son las implementaciones concretas, en el mundo real, que un grupo particular usó para llevar a cabo una técnica. Subir por esa escalera, del procedimiento a la técnica y a la táctica, es lo que convierte un montón de artefactos de incidente en un patrón frente al cual puedes defenderte. **Las capas TTP en ATT&CK** | Capa | Pregunta que responde | Sentido ilustrado | | --- | --- | --- | | Táctica | ¿Por qué el adversario hace esto? | El objetivo de un paso, como la persistencia o el movimiento lateral | | Técnica | ¿Cómo, en general, lo logran? | Un método con nombre y un identificador ATT&CK estable, a veces dividido en subtécnicas | | Procedimiento | ¿Cómo lo hizo exactamente este grupo? | La implementación específica observada en una intrusión real | La razón por la que los profesionales valoran esta estructura es que las defensas construidas a nivel de técnica sobreviven más tiempo que las defensas basadas en indicadores. Un atacante puede cambiar un dominio malicioso o recompilar una carga útil en minutos, derrotando el bloqueo basado en firmas, pero cambiar la técnica subyacente exige más esfuerzo y a menudo más habilidad. Las detecciones ancladas a técnicas envejecen por tanto más despacio y atrapan variantes que la primera firma nunca vio. ## Cómo los equipos ponen ATT&CK a trabajar La defensa informada por amenazas es la práctica que ATT&CK habilita, y se manifiesta en toda la función de seguridad. Los equipos de SOC etiquetan las reglas de detección con identificadores de técnicas para ver, de un vistazo, qué comportamientos adversarios pueden detectar y cuáles se les escapan. Ese análisis de brechas, a menudo visualizado como un mapa de calor sobre la matriz, dirige hacia dónde va el siguiente esfuerzo de detección. Los red teams y los purple teams usan la matriz para diseñar y puntuar ejercicios, recorriendo técnicas deliberadamente para comprobar si el blue team las nota. Los equipos de inteligencia de amenazas describen los grupos adversarios en términos de ATT&CK para que los informes sean comparables en lugar de prosa a medida. Y los programas de formación se apoyan en él porque ofrece a los analistas un modelo único y bien documentado del comportamiento de los atacantes para aprender, en lugar de mil relatos de guerra inconexos. > **Mapea tu cobertura, luego cierra las brechas** El primer movimiento de mayor valor es un mapa de cobertura: etiqueta tus detecciones y controles existentes a las técnicas de ATT&CK y observa dónde se ilumina la matriz y dónde permanece oscura. Las celdas oscuras son tus puntos ciegos en términos del atacante, y esa imagen es mucho más accionable que una lista de herramientas que posees. ATT&CK se publica abiertamente, es gratuito de usar y se actualiza de forma continua a medida que se observa nuevo comportamiento adversario, motivo por el cual se ha convertido en la referencia de facto en lugar de un marco de un fabricante entre muchos. Se combina de forma natural con los catálogos de controles y los sistemas de gestión: donde ISO/IEC 27001, el NIST Cybersecurity Framework o los CIS Controls te dicen qué capacidades de protección y detección construir, ATT&CK te dice qué comportamientos adversarios deben abordar esas capacidades, y cada vez se usa más para priorizar y validar ese trabajo. --- ## Mínimo privilegio **URL:** https://cyberacademy.net/es/resources/encyclopedia/least-privilege **Last reviewed:** 2026-06-24 El mínimo privilegio es el principio según el cual cada identidad (humana o de máquina) recibe los permisos mínimos necesarios para su función, y ninguno más. Parece obvio; rara vez se aplica. La mayoría de los incidentes de exfiltración de datos comienzan con una cuenta de servicio con permisos excesivos que nadie sabía justificar cuando se preguntaba. Combinar con revisiones periódicas de accesos. ## El principio, y por qué sigue fallando en la práctica El privilegio mínimo es fácil de enunciar y difícil de vivir. Cada identidad, ya sea una persona, una cuenta de servicio, un script de automatización o una clave de API, debería poseer exactamente los permisos que su tarea requiere y nada más. El fallo rara vez es una decisión deliberada de otorgar permisos en exceso. Es acumulación. Alguien necesita derechos de administrador para una migración puntual y la concesión nunca se retira. Una cuenta de servicio se crea con ámbitos amplios porque restringirlos exigiría una tarde de pruebas que nadie tiene tiempo de hacer. A un equipo se le asigna un rol diseñado para otro equipo porque era lo más parecido disponible. Con los meses, las identidades acumulan permisos como un escritorio acumula papeles, y nadie sabe explicar por qué cualquiera de ellos está ahí. Esa acumulación es la superficie de ataque. Cuando una cuenta con permisos excesivos es objeto de phishing, se filtra o se abusa de ella de forma silenciosa, el radio de impacto es todo aquello que esa cuenta podía tocar, que suele ser mucho más que su trabajo real. La disciplina del privilegio mínimo no está en la concesión inicial, que es la parte fácil. Está en el trabajo continuo de retirar lo que ya no se necesita y de poder justificar lo que permanece. ## Cómo lo implementan realmente los profesionales El privilegio mínimo es un hábito operativo respaldado por herramientas, no una configuración puntual. El trabajo se agrupa en torno a unas pocas actividades recurrentes: - Diseño de roles y permisos: construir los roles en torno a las funciones del puesto, de modo que conceder acceso sea una correspondencia deliberada y no una copia de lo que tenía la persona anterior. - Acceso justo a tiempo y justo lo suficiente: conceder derechos elevados durante la ventana en que se necesitan y retirarlos automáticamente después, en lugar de dejar establecidos permisos de administración permanentes. - Revisiones de acceso: reexaminar periódicamente quién posee qué y exigir que un responsable confirme que cada concesión sigue estando justificada. Todo lo que nadie quiera avalar se revoca. - Separación de funciones: dividir las acciones sensibles de modo que ninguna identidad pueda a la vez iniciar y aprobar una operación de alto riesgo, lo que equivale a aplicar el privilegio mínimo a los flujos de trabajo en lugar de a los datos. - Identidades de máquina: tratar las cuentas de servicio, los tokens y las credenciales de pipeline con el mismo rigor que a los usuarios humanos, porque suelen ser las que más permisos acumulan y las menos revisadas. > **La cuenta de servicio injustificable** Cuando una revisión de acceso llega a una cuenta y nadie en la sala sabe decir para qué sirve ni por qué tiene el ámbito que tiene, eso es la señal, no la excepción. La mayoría de los incidentes de exfiltración de datos se remontan precisamente a este tipo de identidad olvidada y con permisos excesivos. La respuesta correcta es revocar y ver qué se rompe de forma controlada, no dejarla porque la eliminación parezca arriesgada. ## Dónde se sitúa entre el zero trust, el IAM y el PAM El privilegio mínimo es un principio. Los términos vecinos son la maquinaria que lo materializa. La gestión de identidades y accesos (IAM) es el sistema que define las identidades y lo que pueden hacer, de modo que el privilegio mínimo es la regla que el IAM debe hacer cumplir. La gestión de accesos privilegiados (PAM) es la disciplina más estricta aplicada a las cuentas de mayor riesgo, donde el privilegio mínimo importa más y donde suele residir la elevación justo a tiempo. El zero trust es la arquitectura más amplia que asume que ninguna identidad es de confianza por defecto y verifica cada solicitud; el privilegio mínimo es uno de sus mecanismos centrales, porque verificar una solicitud solo ayuda si el acceso que se concede ya es mínimo. Se puede sostener el principio sin las herramientas, pero a cualquier escala real el principio sin IAM, PAM y revisiones periódicas se degrada silenciosamente de nuevo en sobreaprovisionamiento. La idea está entretejida en las normas incluso donde la frase exacta varía. El Anexo A de la ISO/IEC 27001 aborda el control de acceso, los derechos de acceso privilegiado y la revisión periódica de los derechos de acceso de los usuarios. La familia de control de acceso del NIST se construye en torno al privilegio mínimo y la separación de funciones como principios nombrados. Los CIS Controls exigen un uso controlado de los privilegios administrativos y la gestión de cuentas. Los auditores no solo quieren ver que el acceso se concedió correctamente una vez. Esperan evidencia de un ciclo de revisión continuo, y una cuenta de administración permanente que nadie revisa se trata como un hallazgo, no como una comodidad. --- ## NIS 2 Directive (NIS 2) **URL:** https://cyberacademy.net/es/resources/encyclopedia/nis-2 **Last reviewed:** 2026-06-24 NIS 2 es la directiva europea que responsabiliza directamente a los consejos de administración en materia de ciberseguridad. Si su organización tiene un tamaño mediano o superior y opera en alguno de los 18 sectores enumerados, está dentro del ámbito de aplicación. El reloj empieza a correr desde el primer incidente significativo: alerta temprana en 24 horas, notificación en 72 horas, informe completo al mes. Las sanciones son contundentes (10 millones de euros o el 2% del volumen de negocio mundial). El estado de transposición varía según el país. ## Lo que NIS 2 cambia realmente NIS 2 es la segunda iteración de la Directiva europea sobre seguridad de las redes y de la información, y amplía considerablemente el alcance respecto al régimen NIS original. Donde la primera directiva se apoyaba en las autoridades nacionales para identificar a los operadores de servicios esenciales caso por caso, NIS 2 fija criterios de autoidentificación: si opera en uno de los sectores listados y supera el umbral de tamaño, está dentro del ámbito de aplicación y se espera que lo sepa. La directiva clasifica a las organizaciones afectadas en dos niveles, entidades "esenciales" e "importantes", lo que afecta principalmente a cómo se aplican la supervisión y la ejecución más que a las obligaciones de base en sí. El cambio principal es la rendición de cuentas. NIS 2 hace que los órganos de dirección sean responsables de aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad, y espera que sigan una formación para poder ejercer realmente esa supervisión. La seguridad deja de ser algo que el departamento de TI gestiona discretamente y se convierte en un tema de gobernanza que el consejo debe aprobar. Esa es la razón práctica por la que la directiva se resume tan a menudo como "poner a los consejos en el punto de mira". ## Ámbito de aplicación, sectores y la prueba de tamaño El ámbito de aplicación se basa en dos preguntas: ¿opera en un sector listado y es lo bastante grande? La directiva cubre sectores divididos entre las categorías de "alta criticidad" y "otros sectores críticos", que abarcan energía, transporte, banca, salud, agua, infraestructura digital, administración pública, servicios postales, fabricación de determinados productos, alimentación y más. La prueba de tamaño suele abarcar a las organizaciones medianas y grandes, y a veces incluye a entidades más pequeñas cuando su papel es crítico con independencia de su plantilla. Como los Estados miembros pueden designar entidades adicionales, el único enfoque seguro es cartografiar sus propias actividades frente a los anexos sectoriales en lugar de suponer que es demasiado pequeño para importar. > **Una directiva, no un reglamento** NIS 2 es una directiva, por lo que no se aplica directamente como lo hacen DORA o el RGPD. Cada Estado miembro la transpone a su derecho nacional, lo que significa que la autoridad exacta, el proceso de registro y el detalle de la supervisión varían de un país a otro. Compruebe siempre el texto de transposición en las jurisdicciones donde opera. ## El reloj de la notificación de incidentes Lo que los profesionales sienten de forma más directa es el calendario de notificación, que se activa ante un incidente significativo. Se desarrolla por fases: una alerta temprana en un plazo de 24 horas, una notificación más completa en un plazo de 72 horas y un informe final al cabo de un mes, siendo el destinatario la autoridad competente o el CSIRT. El objetivo del modelo escalonado es sacar a la luz los incidentes con rapidez sin imponer una imagen forense completa el primer día. Para cumplirlo necesita una detección que señale la gravedad con rapidez, un responsable de decisión que pueda clasificar un incidente y plantillas de notificación predefinidas para que el reloj no le pille redactando desde cero. El calendario se apoya en obligaciones de gestión de riesgos que se leen como un socle conocido: tratamiento de incidentes, continuidad de negocio y copias de seguridad, seguridad de la cadena de suministro, desarrollo y mantenimiento seguros, tratamiento de vulnerabilidades, uso de la criptografía, control de acceso y autenticación multifactor, y políticas para comprobar lo bien que funciona todo ello. Nada de esto es exótico. Una organización que opera un SGSI maduro, por ejemplo alineado con ISO 27001, ya cubre la mayor parte del terreno; el trabajo consiste en correlacionar los controles existentes con las expectativas de NIS 2 y cerrar las brechas de gobernanza y notificación. ## Lo que significa en la práctica estar dentro del ámbito de aplicación Si concluye que está dentro del ámbito de aplicación, el programa práctico es bastante constante: registrarse ante la autoridad nacional competente cuando proceda, formalizar la supervisión del riesgo cibernético a nivel del consejo, documentar sus medidas de gestión de riesgos frente a los epígrafes de la directiva, poner en marcha un proceso de clasificación y notificación de incidentes capaz de cumplir las ventanas de 24/72 horas y un mes, y extender la diligencia debida a su cadena de suministro porque los proveedores forman explícitamente parte del panorama de riesgos. La ejecución tiene dientes, con multas que alcanzan decenas de millones de euros o un porcentaje de la facturación mundial, además de la posibilidad de responsabilidad de la dirección, que es exactamente por lo que la directiva empuja la responsabilidad hacia arriba. --- ## NIST Cybersecurity Framework (NIST CSF) **URL:** https://cyberacademy.net/es/resources/encyclopedia/nist-csf **Last reviewed:** 2026-06-24 NIST CSF es el marco de ciberseguridad publicado por el Instituto Nacional de Estándares y Tecnología de EE. UU. La revisión 2.0 (2024) incorporó «Govern» a las cinco funciones existentes (Identify, Protect, Detect, Respond, Recover). No es certificable; se utiliza como referencia de madurez. Complemento habitual de ISO 27001 en organizaciones transatlánticas. ## Qué es el NIST CSF y qué no es El NIST Cybersecurity Framework es una manera estructurada de organizar un programa de ciberseguridad en torno a resultados, en lugar de productos. No le dice qué cortafuegos comprar ni qué control desplegar. En cambio, describe cómo es lo correcto, agrupando la actividad de ciberseguridad en un pequeño conjunto de funciones y dividiendo cada función en categorías y subcategorías que se leen como resultados en lenguaje claro: los activos están inventariados, el acceso está gestionado, las anomalías se detectan, los planes de respuesta se ejecutan. Esa orientación a resultados es la razón por la que se adapta tan bien a distintos sectores y tamaños. Un hospital, un fabricante y un proveedor de software pueden usar todos el mismo vocabulario para describir dónde se encuentran y dónde quieren estar. Lo más importante que hay que entender es lo que el marco no es. No es una norma certificable. No existe un certificado NIST CSF, ni un organismo acreditado que emita una aprobación, ni una auditoría que termine con una marca registrada en su sitio web. Es una referencia voluntaria que se utiliza para evaluar la madurez, fijar objetivos y comunicar la postura, tanto internamente ante un consejo de administración como externamente ante socios. Considere la afirmación de un proveedor de estar «certificado en NIST CSF» como una señal de alerta, porque no existe tal certificación. ## Las funciones: de cinco a seis El marco se estructura en torno a funciones que, en conjunto, cubren todo el ciclo de vida de la gestión del ciberriesgo. Las cinco originales eran Identify, Protect, Detect, Respond y Recover. La revisión 2.0 publicada en 2024 añadió Govern, elevando el total a seis y situando la gobernanza en el centro del modelo en lugar de tratarla como algo secundario. Govern abarca el contexto organizativo, la estrategia de gestión de riesgos, los roles y responsabilidades, la política y la supervisión que deberían determinar cómo se priorizan y dotan de recursos las otras cinco funciones. Su incorporación formalizó lo que los programas maduros ya hacían: los controles técnicos solo funcionan cuando alguien es responsable de las decisiones de riesgo que los sustentan. **Las seis funciones del NIST CSF 2.0** | Función | Qué abarca | | --- | --- | | Govern | Estrategia, roles, política y supervisión del ciberriesgo | | Identify | Comprender los activos, los proveedores y los riesgos que los afectan | | Protect | Salvaguardas que limitan o contienen un incidente | | Detect | Detectar eventos y anomalías a medida que se producen | | Respond | Actuar sobre un incidente detectado para contenerlo | | Recover | Restaurar las capacidades y los servicios tras un incidente | En la práctica, un equipo evalúa su estado actual frente a cada categoría, define un perfil objetivo que refleja su apetito de riesgo y sus obligaciones, y trabaja para cerrar la brecha entre ambos. El marco deja deliberadamente el cómo en sus manos, razón por la cual se combina de forma natural con catálogos prescriptivos como los CIS Controls o NIST 800-53, que aportan las salvaguardas concretas bajo cada resultado. ## Por qué se sitúa junto a ISO 27001 El NIST CSF e ISO 27001 no son competidores, y muchas organizaciones transatlánticas utilizan ambos. ISO 27001 certifica que usted opera un sistema de gestión de la seguridad de la información, con una evaluación de riesgos, una declaración de aplicabilidad y mejora continua, y produce un certificado auditable que los clientes reconocen en todo el mundo. El NIST CSF le ofrece un lenguaje de madurez flexible y una forma de expresar su postura ante un público de orientación estadounidense o de alinearse con las expectativas federales de Estados Unidos. Un patrón común consiste en certificar el sistema de gestión bajo ISO 27001 para obtener la credencial, y luego usar el perfil CSF para comunicar la madurez y alinearse con marcos y clientes que hablan en términos NIST. NIST publica referencias informativas que correlacionan las subcategorías del CSF con ISO 27001 y otras normas, de modo que el trabajo rara vez tiene que hacerse dos veces. > **Sin certificado, por diseño** El NIST CSF es una referencia de madurez voluntaria, no una norma certificable. Si necesita una marca auditable que los clientes reconozcan, esa es ISO 27001. Utilice el CSF para evaluar, fijar objetivos y comunicar, y combínelo con un catálogo de controles para cerrar realmente las brechas. --- ## NIST SP 800-171 **URL:** https://cyberacademy.net/es/resources/encyclopedia/nist-800-171 **Last reviewed:** 2026-06-24 NIST SP 800-171 es el estándar estadounidense que define los requisitos de seguridad para proteger la información no clasificada controlada en sistemas no federales. Es la base técnica de CMMC para los contratistas de defensa. La revisión 3 (2024) endureció los controles. Si vende al Departamento de Defensa de EE. UU., su cumplimiento es obligatorio; si opera únicamente en Europa, tiene carácter informativo. ## Qué exige realmente NIST SP 800-171 Cuando el gobierno de EE. UU. comparte datos sensibles pero no clasificados con un contratista, una universidad o un proveedor de servicios, necesita la garantía de que esos datos estarán protegidos aunque ahora residan fuera de los sistemas federales. NIST SP 800-171 es el catálogo de requisitos de seguridad que responde a esa necesidad. Indica a cualquier organización no federal que maneje Controlled Unclassified Information cómo protegerla: a través del control de acceso, la concienciación y la formación, la auditoría y la rendición de cuentas, la gestión de la configuración, la identificación y la autenticación, la respuesta a incidentes, el mantenimiento, la protección de soportes, la protección física, la seguridad del personal, la evaluación de riesgos, la evaluación de la seguridad, la protección de sistemas y comunicaciones, y la integridad de los sistemas y de la información. El objetivo es la uniformidad. En lugar de que cada agencia invente sus propias cláusulas, los contratistas cumplen una base coherente y única. Los requisitos se derivan del catálogo de controles mucho más amplio NIST SP 800-53 utilizado dentro de los sistemas federales, pero adaptados a la realidad de una organización privada. Se formulan como resultados que se deben alcanzar, no como un único producto o arquitectura prescritos, lo que da a una organización margen para implementarlos de una forma que se ajuste a sus propios sistemas. De lo que no se dispone es de discrecionalidad sobre si cumplirlos o no. Cuando el requisito aparece en su contrato, implementarlo es una condición para conservar ese contrato. ## Los CUI y por qué la cuestión del alcance importa más que ninguna otra Todo en NIST SP 800-171 depende de una pregunta previa: ¿dónde residen realmente los Controlled Unclassified Information en su entorno? Los CUI son información que el gobierno crea o posee, o que una organización crea para el gobierno, que requiere salvaguarda en virtud de una ley, un reglamento o una política de alcance gubernamental, pero que no está clasificada. Abarca categorías como planos técnicos, datos sujetos a control de exportación, información de identificación personal conservada en nombre de una agencia y material sensible similar. La norma solo se aplica a los sistemas que almacenan, procesan o transmiten esos datos. Por eso la definición del alcance es el trabajo que determina todo lo demás. Defina la frontera de forma demasiado amplia e impondrá controles de nivel federal a toda su red con un coste enorme. Defínala de forma demasiado estrecha y dejará CUI expuestos en un sistema que olvidó contabilizar. La mayor parte de un programa 800-171 creíble se dedica a identificar los CUI, aislar los sistemas que los tocan y reducir esa frontera para que los controles recaigan donde realmente se necesitan y no en todas partes. > **El alcance antes que los controles** No puede proteger los Controlled Unclassified Information hasta que sepa dónde están. Mapee primero los flujos de datos CUI y defina la frontera de su sistema; los controles son mucho más baratos de implementar frente a un enclave pequeño y bien aislado que frente a toda una red corporativa. ## Dónde termina 800-171 y dónde empieza CMMC NIST SP 800-171 es el catálogo de controles. La Cybersecurity Maturity Model Certification (CMMC) es el mecanismo de verificación que el Department of Defense de EE. UU. construyó sobre él. Durante años, los contratistas autocertificaban que cumplían el 800-171, y la brecha entre la atestación y la realidad solo salía a la luz tras un incidente. CMMC Level 2 se corresponde directamente con NIST SP 800-171, pero añade una evaluación independiente, de modo que una firma ya no basta. Si implementa realmente el 800-171, ha hecho la mayor parte del trabajo de fondo para CMMC Level 2; lo que queda es producir evidencias y superar una evaluación realizada por alguien que no es usted. La Revision 3, publicada en 2024, reestructuró y endureció los requisitos, reorganizó las familias de controles y trasladó algunos aspectos concretos a una publicación de evaluación complementaria. Para un proveedor europeo, la relevancia es enteramente contractual. Si subcontrata a un prime estadounidense, fabrica componentes de defensa o procesa CUI para un programa del DoD, el 800-171 le obliga igual que obliga a una empresa estadounidense. Si su mercado es puramente europeo, es un contexto informativo que le ayuda a leer CMMC y los requisitos de contratación pública de EE. UU., y se combina de forma natural con la disciplina basada en el riesgo del NIST Cybersecurity Framework en lugar de sustituirla. --- ## No conformidad (NC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/non-conformity **Last reviewed:** 2026-06-24 Una no conformidad es el hallazgo del auditor de que un requisito no se cumple. Las NC mayores ponen en riesgo el certificado; las NC menores exigen un plan de acción correctiva con plazo. Las NC menores repetidas en la misma área pueden escalar a mayores en la siguiente auditoría de seguimiento. El objetivo no es cero NC, sino una acción correctiva honesta y trazable. ## Qué es realmente una no conformidad Una no conformidad registra una brecha entre lo que exige un requisito y lo que un auditor puede constatar en la práctica. El requisito puede provenir de la propia norma (por ejemplo, una cláusula de ISO/IEC 27001), de un control que usted declaró aplicable en su Declaración de Aplicabilidad, o de su propia política documentada. Si lo escribió y se comprometió a ello, un auditor puede exigirle que lo cumpla. Ese último punto pilla desprevenidos a los equipos: prometer de más en una política crea no conformidades que la norma por sí sola nunca habría generado. Una no conformidad no es lo mismo que una observación o una oportunidad de mejora. Una observación señala algo que el auditor quiere dejar constancia sin afirmar que se incumple un requisito. Una no conformidad es una afirmación definitiva de que un requisito no se cumple, respaldada por evidencia objetiva como un registro, una entrevista o un artefacto faltante. La distinción importa porque solo las no conformidades obligan a una respuesta formal. ## Mayor frente a menor, y cómo las menores escalan Los auditores clasifican los hallazgos por su impacto en el sistema de gestión, no por lo molestos que les resulten. Una no conformidad mayor significa que un requisito está fundamentalmente ausente, o que un fallo es lo bastante generalizado como para socavar la confianza en que el sistema funciona. Las mayores ponen en riesgo la decisión de certificación y suelen tener que cerrarse antes de que la certificación o la recertificación pueda continuar. Una no conformidad menor es un desliz aislado en un proceso que por lo demás funciona: una única revisión faltante, un registro que no se firmó. La trampa está en tratar las menores como inofensivas. El mismo hallazgo menor en la misma área, auditoría tras auditoría, le indica al auditor que su acción correctiva nunca solucionó la causa raíz. En la siguiente auditoría de seguimiento ese patrón puede reclasificarse como mayor, porque un control que sigue fallando de la misma forma no está operando realmente. **Cómo suelen ponderar los auditores las no conformidades** | Aspecto | NC menor | NC mayor | | --- | --- | --- | | Alcance | Desliz aislado y contenido | Ausencia sistémica o total de un requisito | | Efecto en el certificado | El certificado normalmente sigue adelante | Puede bloquear o suspender la certificación | | Respuesta requerida | Plan de acción correctiva con un plazo | A menudo corrección más reverificación in situ o por evidencia | | Si se repite | Puede escalar a mayor la próxima vez | Ya en lo más alto de la escala | ## Qué hacen realmente los profesionales con una Cerrar bien una no conformidad es un proceso, no una disculpa. El patrón reconocido es corrección, luego acción correctiva, luego verificación de la eficacia. La corrección es el arreglo inmediato del caso concreto que el auditor encontró. La acción correctiva es el movimiento más profundo: un análisis de causa raíz que explica por qué existía la brecha y un cambio que evita que se repita. La verificación confirma, con evidencia y tras haber transcurrido tiempo suficiente, que el cambio realmente se mantuvo. Cada uno de estos elementos pertenece a un plan de acción correctiva con un responsable y un plazo realista que el auditor acepte. La evidencia que presente debería permitir que alguien que no estuvo en la sala reconstruya lo ocurrido y confirme que está cerrado. Aquí es donde la honestidad rinde frutos: un auditor prefiere ver un número reducido de acciones correctivas bien trazadas que un informe de apariencia impecable que no resiste el escrutinio. > **Cero no es el objetivo** Una auditoría de seguimiento que no encuentra ninguna no conformidad puede leerse como un sistema que nadie está poniendo a prueba. El resultado creíble es una lista manejable de hallazgos, cada uno con una causa raíz documentada y una acción correctiva trazable que se cierra a tiempo. --- ## Objetivos de Tiempo de Recuperación y Punto de Recuperación (RTO / RPO) **URL:** https://cyberacademy.net/es/resources/encyclopedia/rto-rpo **Last reviewed:** 2026-06-24 RTO es la duración máxima aceptable durante la cual un proceso de negocio puede permanecer inactivo antes de causar daños inaceptables. RPO es la pérdida máxima de datos medida en tiempo anterior a la interrupción. Ambos se derivan del BIA. Los valores que el CIO escribe en el BCP sin consultar al negocio son los valores que fallan bajo presión. ## Dos relojes que miden cosas diferentes El RTO y el RPO son los dos objetivos de recuperación que convierten una promesa vaga de resiliencia en cifras comprobables. Es fácil confundirlos porque ambos se expresan en unidades de tiempo, pero miden cosas diferentes y apuntan a soluciones diferentes. El recovery time objective trata de cuánto tiempo puedes estar caído. El recovery point objective trata de cuántos datos puedes permitirte perder. Si los confundes, comprarás la arquitectura de recuperación equivocada. Imagina la interrupción como un único instante en una línea de tiempo. El RTO mira hacia adelante desde ese instante: es la ventana máxima entre el corte y el momento en que el proceso vuelve a ser utilizable, antes de que el daño resulte inaceptable. El RPO mira hacia atrás desde ese instante: es la antigüedad máxima de la última copia válida de datos a la que puedes recuperar, lo que equivale a los datos más recientes que estás dispuesto a perder. Un RTO de cuatro horas con un RPO de quince minutos significa que el servicio debe restablecerse en menos de cuatro horas y no puede perder más de quince minutos de transacciones. **RTO comparado con RPO** | | RTO | RPO | | --- | --- | --- | | Mide | Tiempo de inactividad aceptable | Pérdida de datos aceptable | | Dirección en la línea de tiempo | Hacia adelante desde la interrupción | Hacia atrás desde la interrupción | | Pregunta que responde | ¿Con qué rapidez debemos restablecernos? | ¿Cuántos datos podemos perder? | | Determinado principalmente por | Proceso de recuperación, conmutación por error, personal | Frecuencia de copia de seguridad y replicación | | Fuente | Análisis de impacto en el negocio | Análisis de impacto en el negocio | ## De dónde salen las cifras y por qué importa la responsabilidad Ambos objetivos son resultados del análisis de impacto en el negocio, no conjeturas hechas en la sala de servidores. El BIA estudia cada actividad crítica, mide cómo crece con el tiempo el daño de un corte y produce objetivos de recuperación que el responsable del proceso valida. Esa responsabilidad es precisamente el punto clave. Un RTO y un RPO que un equipo técnico fija de forma aislada describen lo que la infraestructura puede hacer, no lo que el negocio necesita, y la brecha entre ambos solo aflora durante un incidente real, que es el peor momento para descubrirla. Los objetivos también deben conciliarse con el coste. Llevar un RPO hacia cero implica replicación continua o síncrona. Llevar un RTO hacia los minutos implica capacidad de respaldo en caliente que permanece inactiva. Ambos son costosos, así que el BIA fuerza una conversación honesta sobre qué procesos justifican realmente ese gasto y cuáles pueden tolerar una ventana más larga. Escalonar las actividades por niveles es normal: el motor de pagos y el sitio de marketing rara vez merecen los mismos objetivos. > **El RTO no es lo mismo que cuánto tarda la recuperación** El RTO es el objetivo que el negocio puede tolerar. El tiempo real que tu equipo necesita para restablecer el servicio es el recovery time achieved, medido en una prueba. Si el tiempo logrado es mayor que el objetivo, tienes una brecha que cerrar, no una cifra que relajar discretamente. ## Cómo encajan el RTO y el RPO en las normas Estos objetivos son vocabulario fundamental en los marcos de continuidad y resiliencia. ISO 22301, la norma internacional para los sistemas de gestión de la continuidad del negocio, trata los recovery time y recovery point objectives como resultados del análisis de impacto que impulsan la estrategia y las soluciones de continuidad. Fluyen directamente al diseño de la recuperación ante desastres, los calendarios de copias de seguridad y la elección de los sitios de recuperación. En los sectores regulados se examinan cada vez más en lugar de darse por supuestos: el Reglamento de Resiliencia Operativa Digital de la UE (DORA) fija expectativas de continuidad y prueba para las entidades financieras, y la Directiva NIS 2 exige medidas de continuidad del negocio y de copia de seguridad a las entidades esenciales e importantes. Los profesionales hacen tres cosas con estas cifras. Las derivan del BIA junto con los responsables de negocio. Diseñan la copia de seguridad, la replicación y la conmutación por error para que la arquitectura pueda cumplirlas realmente. Luego lo demuestran mediante pruebas, porque un RTO no probado es una aspiración. El objetivo solo gana confianza una vez que un ejercicio de recuperación ha demostrado que el equipo puede alcanzarlo en condiciones realistas. --- ## PCI DSS **URL:** https://cyberacademy.net/es/resources/encyclopedia/pci-dss **Last reviewed:** 2026-06-24 PCI DSS es el estándar de seguridad de datos del sector de tarjetas de pago. Es obligatorio para cualquier organización que almacene, procese o transmita datos de titulares de tarjetas. La versión 4.0.1 es la revisión vigente, plenamente obligatoria desde el 31 de marzo de 2025. La reducción de alcance (tokenización, segmentación) es donde se concentra el mayor valor; «cumple o no cumple» es binario, pero la dimensión del alcance lo es todo. ## Qué regula realmente PCI DSS PCI DSS es la base de seguridad que imponen las principales marcas de tarjetas de pago a toda organización que almacene, procese o transmita datos de titulares de tarjetas. No es una ley ni una regulación gubernamental. Es un requisito contractual, exigido a través de los bancos adquirentes y de las redes de tarjetas que se sitúan por encima de ellos. Si manejas un número de cuenta principal, la norma se te aplica, ya seas un minorista global o una pequeña tienda de comercio electrónico que opera una única página de pago. La norma se organiza en torno a un conjunto de objetivos de control que abarcan a las personas, los procesos y la tecnología que entran en contacto con los datos de titulares de tarjetas: construir y mantener una red segura, proteger los datos de cuenta almacenados, cifrar la transmisión, gestionar las vulnerabilidades, restringir el acceso según el principio de necesidad de conocer, supervisar y registrar, y mantener una política escrita de seguridad de la información. Cada objetivo se descompone en requisitos concretos y verificables, razón por la cual PCI DSS se lee más como una lista de comprobación de auditoría que como un marco basado en principios como ISO 27001. ## El alcance lo es todo La decisión más importante para el profesional no es cómo superar la evaluación, sino cómo reducir lo que se evalúa. Todo lo que almacena, procesa o transmite datos de titulares de tarjetas, junto con cualquier elemento conectado a ello, queda dentro del entorno de datos de titulares de tarjetas (CDE). Cuanto mayor es el CDE, más sistemas deben cumplir cada requisito y más penosa y costosa resulta la evaluación. Aquí es donde la tokenización, la segmentación de la red y la externalización a proveedores de pago conformes justifican su valor. Al sustituir los números de tarjeta por tokens, aislar el CDE detrás de cortafuegos y trasladar la captura real de la tarjeta a una página alojada o a un procesador externo, retiras sistemas por completo del alcance. Un entorno bien segmentado puede reducir un parque desbordado a un puñado de componentes que requieren validación completa. > **El cumplimiento es binario, el alcance no** O cumples todos los requisitos aplicables o no los cumples; no hay crédito parcial. Pero el tamaño al que reduces el entorno de datos de titulares de tarjetas determina cuánto esfuerzo cuesta ese resultado binario. La reducción del alcance es la única acción de mayor apalancamiento en cualquier programa PCI. ## Cómo funciona la validación en la práctica La forma en que demuestras el cumplimiento depende del volumen de transacciones y de cómo aceptas los pagos. Los comercios más pequeños suelen completar un Cuestionario de Autoevaluación (SAQ), eligiendo la versión que corresponde a su canal de aceptación. Los comercios y proveedores de servicios de mayor tamaño se someten a una evaluación formal a cargo de un Qualified Security Assessor (QSA), que elabora un Report on Compliance. El escaneo de red por parte de un Approved Scanning Vendor y la presentación de pruebas trimestrales son obligaciones habituales en todos los niveles. La revisión actual, la versión 4.0.1, va más allá de una mera lista de comprobación. Junto al «enfoque definido» prescriptivo, introduce un «enfoque personalizado» que permite a las organizaciones maduras cumplir un objetivo de control mediante sus propios controles diseñados, siempre que puedan documentar y evidenciar que el objetivo se cumple. También reformula el cumplimiento como un estado continuo en lugar de una instantánea anual, con varios requisitos que exigen explícitamente una supervisión integrada en las operaciones cotidianas. ## Cómo se sitúa junto a otras normas Los equipos confunden a menudo PCI DSS con ISO 27001. Se solapan, pero responden a preguntas distintas. ISO 27001 certifica que operas un sistema de gestión de seguridad de la información; PCI DSS valida que un conjunto de controles específico y prescrito protege los datos de titulares de tarjetas. Uno es una certificación de sistema de gestión cuyo alcance defines tú mismo; el otro es un conjunto de controles fijo impuesto por un organismo sectorial externo. Operar un SGSI ISO 27001 te aporta una estructura de gobernanza que facilita la producción de las pruebas PCI, pero no sustituye a los requisitos específicos de los datos de tarjetas. **PCI DSS comparado con ISO 27001** | Dimensión | PCI DSS | ISO 27001 | | --- | --- | --- | | Naturaleza | Norma contractual sectorial | Norma internacional certificable | | Impuesta por | Las marcas de tarjetas a través de los bancos adquirentes | Adoptada voluntariamente por la organización | | Alcance | Entorno de datos de titulares de tarjetas (foco fijo) | Lo que la organización defina | | Conjunto de controles | Prescrito y verificable | Impulsado por el riesgo, seleccionado por la organización | | Resultado | Attestation / Report on Compliance | Certificado acreditado | --- ## Phishing **URL:** https://cyberacademy.net/es/resources/encyclopedia/phishing **Last reviewed:** 2026-06-24 El phishing es el ataque de ingeniería social que engaña a un usuario para que haga clic en un enlace malicioso, abra un archivo malicioso o revele credenciales. Variantes: spear phishing (dirigido), whaling (directivos), smishing (SMS), vishing (voz), BEC (compromiso de correo electrónico corporativo). La formación importa; la MFA resistente al phishing importa más. ## Por qué el phishing sigue siendo el principal punto de entrada El phishing perdura porque ataca a la persona, no al perímetro. Todos los demás controles pueden estar perfectamente configurados y el atacante sigue necesitando solo a un empleado que haga clic en un enlace, abra un archivo o escriba una contraseña en una falsificación convincente. El mensaje llega por un canal de confianza, normalmente el correo electrónico pero cada vez más el SMS y la voz, y toma la apariencia y el tono de una marca, un colega o un sistema interno del que la víctima ya espera recibir noticias. Como la carga útil suele residir tras un dominio recién registrado o una página de inicio de sesión en la nube de aspecto legítimo, los filtros basados en firmas y las listas de reputación llegan con frecuencia demasiado tarde. La economía también favorece al atacante: una sola plantilla puede difundirse a miles de destinatarios a un coste casi nulo, y un solo éxito puede entregar credenciales que desbloquean todo lo demás. Lo que vigilan los profesionales es el cambio del volumen a la precisión. El phishing masivo es una red amplia, pero los incidentes costosos suelen empezar con un mensaje a medida que claramente ha hecho los deberes sobre el objetivo, el organigrama y el momento. ## Las variantes que importan en la práctica El phishing es una familia, no una sola técnica. La lógica de la ingeniería social se mantiene constante mientras el canal y el objetivo cambian. - Spear phishing: un mensaje dirigido elaborado para una persona o equipo concretos, que utiliza nombres, proyectos y contexto reales para reducir la sospecha. - Whaling: spear phishing dirigido a directivos y otros aprobadores de alto valor, donde una sola cuenta comprometida conlleva una autoridad desproporcionada. - Smishing: phishing distribuido por SMS, a menudo un aviso falso de entrega, banco o restablecimiento de MFA que explota la pantalla más pequeña y el hábito de confiar en los mensajes de texto. - Vishing: phishing por llamada de voz, donde un atacante presiona a la víctima en tiempo real, cada vez más ayudado por números suplantados y audio sintético. - Business email compromise: un subtipo de pretexting que apunta directamente a los procesos de pago y de datos, normalmente sin ningún enlace ni archivo adjunto malicioso. ## Lo que realmente reduce el riesgo La formación en concienciación es necesaria pero no suficiente. Las personas siempre harán clic en una cierta proporción de los casos, por lo que el objetivo es eliminar el valor de un clic en lugar de exigir la perfección a los usuarios. El control técnico decisivo es la autenticación multifactor resistente al phishing, es decir, factores vinculados al dominio legítimo, como las llaves de seguridad FIDO2 o las passkeys, que una página de inicio de sesión falsa no puede reproducir. Detrás de eso se sitúan, en capas, los controles que atrapan lo que se escapa. - MFA resistente al phishing en cada cuenta que importa, de modo que una contraseña robada por sí sola no baste para iniciar sesión. - Autenticación del correo electrónico con SPF, DKIM y DMARC para aumentar el coste de la suplantación de dominio, junto con una pasarela de correo segura y la reescritura de enlaces o el sandboxing. - Formación en concienciación continua y basada en escenarios, más phishing simulado, medida para mejorar con el tiempo en lugar de para castigar a las personas. - Un botón de notificación sin fricciones y un proceso de respuesta rápido, porque las personas que notifican son el sistema de alerta temprana para las que hicieron clic. > **Forma al humano, pero elimina el clic por diseño** La concienciación reduce la tasa de clic; nunca llega a cero. La MFA resistente al phishing vinculada al dominio real es lo que impide que una credencial robada se convierta en una apropiación de cuenta. Trata la formación como una capa, no como el control. ## El lugar del phishing en las normas y la regulación El phishing se sitúa de lleno dentro del alcance de un sistema de gestión de seguridad de la información. Bajo un SGSI ISO/IEC 27001, el tratamiento pertinente combina formación en concienciación, control de acceso y los controles técnicos de correo y autenticación, todos seleccionados mediante la evaluación de riesgos en lugar de añadidos por reflejo. Las orientaciones europeas de ENISA y de autoridades nacionales como ANSSI clasifican sistemáticamente el phishing entre las principales técnicas de acceso inicial y publican contramedidas prácticas. Cuando un phishing exitoso expone datos personales, por ejemplo a través de un buzón comprometido, también puede activar obligaciones de violación de datos personales en virtud del GDPR, lo que significa que el área legal y la función de protección de datos deben formar parte del plan de respuesta, junto a TI y seguridad. Para los profesionales, la lección es que la defensa contra el phishing es por capas y compartida. Ninguna herramienta ni campaña de concienciación la cierra por sí sola. La postura duradera combina personas, procesos y diseño de la autenticación de modo que un clic, que tarde o temprano ocurrirá, no se convierta en una brecha. --- ## Privacidad desde el diseño y por defecto **URL:** https://cyberacademy.net/es/resources/encyclopedia/privacy-by-design **Last reviewed:** 2026-06-24 La privacidad desde el diseño (artículo 25 del GDPR) es la obligación de integrar los controles de privacidad en los sistemas desde la fase de requisitos. La privacidad por defecto es la obligación de establecer la opción de mayor protección como estándar. Los auditores buscan evidencia documentada (DPIA, revisión de diseño, valores de retención por defecto) y no un eslogan en una política. ## Dos obligaciones, no una La privacidad desde el diseño (privacy by design) y la privacidad por defecto (privacy by default) están redactadas como una única obligación del RGPD, pero exigen dos cosas distintas, y los profesionales se meten en problemas cuando las funden en una sola. Desde el diseño significa que los controles de privacidad se incorporan a un sistema desde la fase de requisitos, antes de que se escriba una línea de código o se elija un proveedor, en lugar de añadirse una vez que empiezan a llegar las solicitudes de acceso de los interesados. Por defecto significa que cuando un usuario no hace nada, el sistema ya se encuentra en su configuración más protectora: la recogida de datos más restringida, la conservación más breve, la compartición más estricta. Una se refiere a cómo construyes; la otra a lo que el sistema hace el primer día sin configuración alguna. La distinción importa porque un equipo puede cumplir una y fallar la otra. Puedes realizar una revisión de diseño exhaustiva, documentar una EIPD y aun así lanzar un producto cuyos ajustes por defecto estén todos configurados para la máxima compartición porque eso es lo que pidió el equipo de crecimiento. Ese producto es privacidad desde el diseño pero no por defecto, y no es conforme. También ocurre lo contrario: un ajuste por defecto conservador añadido a un sistema que nunca se evaluó deja al responsable del tratamiento incapaz de demostrar cómo se tomó la decisión. ## Qué cambia esto realmente en la práctica El cambio práctico consiste en mover la privacidad aguas arriba. En lugar de que el área jurídica revise una funcionalidad terminada, los requisitos de privacidad se convierten en restricciones de diseño que ingeniería y producto asumen desde el primer sprint. La minimización de datos deja de ser un eslogan y se convierte en una pregunta planteada a cada campo de cada formulario: ¿necesitamos esto para prestar el servicio? Y si no, ¿por qué está aquí? La limitación de la finalidad se convierte en una restricción sobre los fines para los que un conjunto de datos podrá reutilizarse después. La conservación se convierte en un calendario por defecto que el sistema aplica, no en una limpieza manual que nadie se acuerda de ejecutar. - Recoge el mínimo de campos que el servicio realmente necesita, y justifica cada uno. - Establece los plazos de conservación como ajustes por defecto aplicados, con supresión o anonimización automática cuando expiren. - Configura los ajustes por defecto de compartición, visibilidad y elaboración de perfiles en la opción menos permisiva, dejando que el usuario opte por autorizar más. - Aplica la seudonimización y el cifrado como opciones arquitectónicas estándar y no como excepciones. - Acota el acceso a los datos personales por finalidad, de modo que un sistema solo exponga lo que una función concreta requiere. > **Los auditores quieren pruebas, no un eslogan** Una línea en una política de privacidad que diga que practicas la privacidad desde el diseño no prueba nada. Lo que resiste el escrutinio son pruebas documentadas de que la obligación se cumplió: una EIPD para los tratamientos de mayor riesgo, registros de revisión de diseño que muestren que la privacidad se consideró antes de construir, y la configuración por defecto real del sistema en producción. Si no puedes mostrar el artefacto, el auditor considera el control como ausente. ## Cómo se sitúa frente a conceptos vecinos La privacidad desde el diseño se entiende más fácilmente por contraste con aquello con lo que la gente la confunde. No es lo mismo que una EIPD, que es una pieza de prueba de que la obligación más amplia se cumplió para una actividad de tratamiento concreta y de mayor riesgo. No es la seguridad desde el diseño, que protege los datos frente a los atacantes con independencia de si esos datos debieron recogerse siquiera; la privacidad desde el diseño empieza un paso antes, cuestionando la propia recogida. Y no es una verificación única. Como los sistemas evolucionan, la obligación es continua: cada nueva funcionalidad, integración o flujo de datos reabre las mismas preguntas sobre minimización, finalidad y ajustes por defecto. En un programa maduro, la privacidad desde el diseño se convierte en un hábito integrado en el ciclo de vida del desarrollo, y no en un punto de control en manos del área jurídica. Producto e ingeniería plantean las preguntas por sí mismos, la EIPD se activa automáticamente cuando el tratamiento cruza un umbral de riesgo, y la configuración por defecto se revisa como parte del lanzamiento en lugar de descubrirse en producción. Esa es la diferencia entre una organización que puede demostrar el principio y otra que simplemente lo afirma. --- ## Privileged Access Management (PAM) **URL:** https://cyberacademy.net/es/resources/encyclopedia/pam **Last reviewed:** 2026-06-24 PAM es el subconjunto de IAM centrado en cuentas privilegiadas: administradores, root, cuentas de servicio y break-glass. Almacena credenciales en bóveda, intermedia sesiones y registra la actividad. Es el primer objetivo del atacante tras el acceso inicial, y el control que los auditores examinan con mayor rigor bajo NIS 2 y DORA. ## Por qué las cuentas privilegiadas son un problema aparte Todo programa de identidad comienza con los usuarios ordinarios: quiénes son, qué pueden abrir, cómo lo demuestran. La gestión de accesos privilegiados (PAM) se ocupa de las cuentas que se sitúan por encima de esa capa. Administradores de dominio, cuentas root y de administrador local, propietarios de bases de datos, consolas de hipervisor, identidades root en la nube, cuentas de servicio que se ejecutan sin supervisión y las cuentas de emergencia reservadas para situaciones críticas. Estas identidades pueden cambiar la configuración, leer o destruir datos, deshabilitar el registro y crear nuevas cuentas. El radio de impacto de una sola credencial de administrador comprometida es todo el entorno, razón por la cual el PAM se trata como una disciplina propia y no como una funcionalidad del IAM general. El gesto definitorio del PAM consiste en dejar de tratar las credenciales privilegiadas como algo que una persona simplemente conoce. En su lugar, el secreto reside en una bóveda, el acceso se solicita y se aprueba, la sesión se canaliza a través de una pasarela controlada y todo lo que hace el usuario privilegiado queda registrado. El humano a menudo nunca llega a ver la contraseña. Esa separación entre el operador y el secreto es lo que hace que la actividad privilegiada sea auditable y revocable. ## Qué controla realmente un programa de PAM En la práctica, una implementación de PAM madura combina varios mecanismos que se corresponden directamente con lo que los auditores esperan ver: - Almacenamiento en bóveda de credenciales: las contraseñas privilegiadas, las claves SSH y los secretos de API se almacenan de forma centralizada, se rotan automáticamente y nunca se incrustan en scripts ni en archivos de configuración. - Intermediación y grabación de sesiones: los administradores se conectan a través de un proxy que inyecta la credencial, de modo que la sesión puede supervisarse, grabarse y terminarse sin que el operador llegue a poseer el secreto. - Elevación justo a tiempo: los derechos se conceden para una tarea definida y una ventana definida, y luego se revocan, en lugar de dejarlos asignados a la cuenta de forma permanente. - Procedimientos de emergencia (break-glass): las cuentas de emergencia están selladas, con alarma y se revisan después de cada uso, de modo que existen para interrupciones genuinas sin convertirse en una puerta trasera silenciosa. - Descubrimiento y rendición de cuentas: la herramienta detecta cuentas privilegiadas y de servicio en todo el parque y vincula cada acción privilegiada a un humano identificado por su nombre. > **El PAM es un control, no un producto** Comprar una bóveda no equivale a implantar el PAM. El control es la combinación de un inventario limpio de cuentas privilegiadas, un flujo de aprobación, la rotación, la grabación de sesiones y la revisión. La herramienta aplica una política que usted todavía tiene que redactar. **El PAM en comparación con el IAM general** | Dimensión | IAM general | PAM | | --- | --- | --- | | Alcance | Todas las identidades y accesos | Solo cuentas privilegiadas (admin, root, servicio, break-glass) | | Pregunta central | ¿Debería esta persona tener acceso? | ¿Cómo se almacena en bóveda, se intermedia y se registra este acceso elevado? | | Gestión de credenciales | El usuario se autentica con su propia credencial | El secreto se almacena en bóveda y se inyecta; el operador puede no verlo nunca | | Postura por defecto | Derechos persistentes gestionados a lo largo del tiempo | Justo a tiempo, limitado en el tiempo, revocado tras su uso | | Foco de la auditoría | Revisiones de acceso y proceso de alta-traslado-baja | Grabación de sesiones, rotación, revisión de cuentas de emergencia | ## Dónde se sitúa el PAM dentro del IAM y el panorama regulatorio El PAM es un subconjunto de la gestión de identidades y accesos, acotado a las cuentas que conllevan mayor riesgo, y es la punta de lanza del principio de mínimo privilegio. El IAM general se pregunta si una persona debería tener acceso siquiera. El PAM da por sentado que el acceso es legítimo, pero insiste en que sea temporal, intermediado, registrado y reversible. Los atacantes comprenden esta jerarquía: tras una primera intrusión mediante phishing o un servicio expuesto, el siguiente objetivo es escalar hacia una cuenta privilegiada, porque eso es lo que convierte un único host en el control del dominio. Los supervisores también lo saben. En virtud de la Directiva NIS 2, el control de acceso y la gestión de las cuentas privilegiadas se enmarcan de lleno en las medidas de gestión de riesgos de ciberseguridad que las entidades esenciales e importantes deben aplicar. El Reglamento de Resiliencia Operativa Digital (DORA) establece expectativas comparables para el sector financiero, donde la autenticación robusta y el control estricto de los accesos privilegiados forman parte del marco de gestión del riesgo de TIC. El Anexo A de la norma ISO/IEC 27001 aborda los derechos de acceso privilegiado y la gestión de la información secreta de autenticación como controles nombrados. En una auditoría, el acceso privilegiado es de forma sistemática una de las áreas examinadas con mayor dureza, porque un control débil en este punto socava todas las demás salvaguardas. ## Modos de fallo habituales Los programas de PAM fracasan de maneras predecibles. Cuentas de servicio con contraseñas sin caducidad codificadas directamente en la automatización. Cuentas de administrador compartidas en las que nadie puede decir quién actuó. Derechos de administrador local permanentes en cada estación de trabajo. Una adopción de la bóveda que cubre a los administradores interactivos pero deja intactas las identidades de máquina. La disciplina solo vale lo que su cobertura, por lo que el trabajo práctico es el descubrimiento continuo y la eliminación constante del privilegio permanente, y no un único despliegue. --- ## Professional Evaluation and Certification Board (PECB) **URL:** https://cyberacademy.net/es/resources/encyclopedia/pecb **Last reviewed:** 2026-06-24 PECB es el organismo de certificación acreditado con sede en Montreal que emite credenciales profesionales sobre más de 30 estándares ISO en más de 150 países. Seguridad de la información, riesgo, BCM, gobernanza de IA, privacidad, calidad. Cyber Academy es PECB Gold Partner. Las credenciales llevan la marca PECB; las cohortes se imparten a través de socios acreditados. ## Qué es realmente PECB PECB (el Professional Evaluation and Certification Board) es un organismo de certificación de personas. No certifica a su empresa según ISO 27001; esa es la función de un organismo de certificación acreditado que audita su sistema de gestión. PECB certifica a personas. Cuando un profesional completa un curso y aprueba el examen, PECB emite una credencial individual que indica que esa persona ha demostrado competencia frente a un esquema definido sobre una norma concreta. El catálogo es amplio porque la cartera de ISO es amplia. Los esquemas de PECB abarcan la seguridad de la información, la gestión del riesgo, la continuidad del negocio, la privacidad y la protección de datos, la gobernanza de la IA y la calidad, entre otros. Esa amplitud es precisamente el objetivo: un profesional puede construir una trayectoria de credenciales coherente dentro de un único organismo emisor en lugar de coleccionar insignias de una docena de fuentes. > **Organismo frente a socio** PECB es propietario del esquema, el examen y el certificado. La formación la imparten socios acreditados que gestionan los grupos. La credencial lleva la marca PECB; la experiencia en el aula la aporta el socio. Cyber Academy es PECB Gold Partner, que es la parte de impartición de este acuerdo. ## Cómo se estructuran las credenciales Los esquemas de PECB suelen estar vinculados a una norma concreta y a un rol concreto. Las combinaciones más conocidas son Lead Implementer, para la persona que construye y opera un sistema de gestión, y Lead Auditor, para la persona que lo audita. Ambas existen para ISO 27001 y para otras normas certificables como ISO 22301 para la continuidad del negocio e ISO 42001 para los sistemas de gestión de la IA. Por debajo se sitúan las credenciales de nivel Foundation, que establecen el vocabulario y los principios antes de que un profesional se comprometa con la trayectoria completa de implementador o auditor. La distinción entre las dos trayectorias sénior importa más de lo que sugiere la etiqueta común «Lead». Un Lead Implementer planifica el alcance, redacta las políticas, impulsa la Declaración de aplicabilidad y opera los controles. Un Lead Auditor trabaja en el otro lado: planificar auditorías, muestrear evidencias, entrevistar e informar de los hallazgos frente a una norma. Son disciplinas complementarias, y muchos profesionales poseen ambas porque operar bien un sistema de gestión y auditarlo requieren capacidades distintas. Una credencial no es lo mismo que la norma subyacente. ISO 27001 es el marco frente al cual se certifica una organización. La credencial de PECB es la prueba de que una persona concreta ha sido evaluada frente a un esquema de competencia construido sobre ese marco. Confundir ambas cosas es el error más común que cometen los recién llegados. ## Dónde se sitúa PECB entre los organismos de certificación Varias organizaciones emiten credenciales de personas alineadas con ISO, y un empleador rara vez se preocupa por el organismo emisor en abstracto. Lo que tiene peso es la norma que respalda la credencial y si el esquema de certificación está acreditado. PECB se posiciona como un organismo acreditado que opera a nivel internacional, lo que confiere al certificado portabilidad a través de las fronteras y reconocimiento por parte de empleadores que no conocen al proveedor de formación. Para un profesional que elige una trayectoria, las preguntas prácticas son: con qué norma necesito trabajar, cubre este esquema el rol que quiero, y está reconocida la credencial donde pretendo ejercer. La marca emisora es la respuesta al reconocimiento; la norma y el rol responden al resto. --- ## Pruebas de penetración **URL:** https://cyberacademy.net/es/resources/encyclopedia/penetration-testing **Last reviewed:** 2026-06-24 Una prueba de penetración es una simulación de ataque autorizada y delimitada en alcance, cuyo objetivo es identificar debilidades explotables antes de que lo hagan atacantes reales. Black box / grey box / white box, interna / externa, de aplicación / de infraestructura. Se distingue del análisis de vulnerabilidades (automatizado, orientado a la amplitud) y del red team (varios meses, basado en objetivos). Los informes resultantes alimentan el backlog de remediación. ## Qué es realmente una prueba de penetración Una prueba de penetración es un intento deliberado y autorizado de irrumpir en un sistema tal como lo haría un atacante real, realizado dentro de un alcance escrito y unas reglas de enfrentamiento. El objetivo no es enumerar debilidades teóricas, sino demostrar cuáles pueden encadenarse realmente para alcanzar algo que importa: una base de datos, una cuenta de administrador, un registro de cliente, un flujo de pago. El analista sigue el mismo camino que un intruso, pero con permiso y un límite definido, de modo que la organización descubra dónde fallaría antes de que lo haga alguien hostil. La autorización es lo que separa una prueba de penetración de un delito; sin un alcance firmado, las mismas acciones no son más que una intrusión. Los encargos se enmarcan en unos pocos ejes que el alcance debe fijar de antemano. El nivel de conocimiento va desde la caja negra, donde el analista parte únicamente de un nombre o un rango de direcciones IP, pasando por la caja gris, donde obtiene una cuenta de bajos privilegios o documentación parcial, hasta la caja blanca, donde recibe el código fuente, los diagramas de arquitectura y credenciales completas. El punto de vista es externo, simulando a un atacante en Internet, o interno, simulando a alguien que ya ha entrado en la red o a un infiltrado malicioso. El tipo de objetivo separa las pruebas de aplicación, que sondean una aplicación web o móvil y su lógica, de las pruebas de infraestructura, que van contra los equipos, los servicios y la configuración de red. La mayoría de los programas reales combinan estos enfoques para ajustarse a las amenazas que realmente les preocupan. ## En qué se diferencia de un escaneo y de un equipo rojo La confusión más común se da entre una prueba de penetración y un escaneo de vulnerabilidades, y no son lo mismo. Un escaneo de vulnerabilidades es automatizado y está optimizado para la amplitud: una herramienta recorre cada activo accesible, compara lo que encuentra con una base de problemas conocidos y produce una larga lista. Es rápido, repetible y barato, pero no puede decirte si un hallazgo determinado es realmente explotable en tu entorno o un falso positivo. Una prueba de penetración la dirige un humano y está optimizada para la profundidad: el analista valida los hallazgos explotándolos realmente, encadena varios problemas de menor gravedad en un compromiso real y pone a prueba la lógica de negocio y los supuestos de confianza que ningún escáner entiende. El escaneo te dice qué podría estar mal; la prueba de penetración te dice qué podría hacer realmente un atacante con ello. En el otro extremo se sitúa el equipo rojo, que también se confunde con frecuencia con la prueba de penetración. Un encargo de equipo rojo es más largo, a menudo se prolonga durante meses, y está orientado a objetivos en lugar de a la cobertura: la meta es alcanzar un resultado concreto, como exfiltrar un conjunto de datos definido o llegar a un sistema en particular, permaneciendo indetectado y comprobando si los defensores lo advierten y responden. Una prueba de penetración busca cobertura dentro de un alcance y suele ser conocida por los equipos pertinentes; un equipo rojo persigue un único objetivo en profundidad y pone a prueba deliberadamente la detección y la respuesta tanto como los propios controles. **La prueba de penetración comparada con un escaneo de vulnerabilidades y un equipo rojo** | Dimensión | Escaneo de vulnerabilidades | Prueba de penetración | Equipo rojo | | --- | --- | --- | --- | | Método | Herramientas automatizadas | Dirigido por un humano, práctico | Dirigido por un humano, emulación de adversario | | Meta | Amplitud: enumerar problemas conocidos | Profundidad: demostrar la explotabilidad en el alcance | Objetivo: alcanzar una meta definida | | Validación | Sin explotación | Hallazgos explotados y encadenados | Cadena de ataque completa hasta el objetivo | | Detección probada | No | Normalmente no | Sí, pone a prueba directamente a los defensores | | Duración típica | De minutos a horas | De días a semanas | De semanas a meses | ## Dónde encaja en un programa de seguridad Una prueba de penetración es una verificación puntual, no un control en sí mismo. Su verdadero valor se materializa después del encargo, cuando el informe alimenta la cola de remediación. Un buen informe hace algo más que enumerar hallazgos: los clasifica por explotabilidad e impacto en el negocio, aporta evidencia reproducible y recomienda correcciones. Esos hallazgos se convierten en tickets, responsables y plazos dentro del proceso más amplio de gestión de vulnerabilidades, y una nueva prueba confirma que las correcciones realmente cerraron los agujeros en lugar de desplazarlos. Sin ese seguimiento, una prueba no es más que un documento caro. La prueba de penetración también aparece explícitamente en las normas y la regulación. Un sistema de gestión de la seguridad de la información alineado con ISO/IEC 27001 trata las pruebas técnicas como una forma de verificar que los controles funcionan en la práctica, y los marcos relativos a los pagos, las infraestructuras críticas y los servicios financieros esperan cada vez más pruebas periódicas y acotadas de los sistemas expuestos a Internet y críticos. ENISA y agencias nacionales como ANSSI publican orientaciones sobre cómo encargar pruebas de manera responsable, y el conjunto de habilidades ofensivas se formaliza en credenciales para hackers éticos. Lo que los profesionales entregan realmente es un ritmo recurrente: acotar el encargo, acordar las reglas de enfrentamiento y una autorización escrita, probar, informar, remediar, volver a probar y repetir a medida que el entorno cambia. > **Una prueba es el comienzo del trabajo, no el final** El entregable que importa no es el informe, sino lo que ocurre después. Los hallazgos clasificados y explotables se convierten en tickets asignados en la cola de remediación, y una nueva prueba demuestra que realmente se cerraron. Una prueba de penetración sin un bucle de remediación detrás otorga una confianza que no se ha ganado. --- ## Pruebas de penetración basadas en amenazas (TLPT) **URL:** https://cyberacademy.net/es/resources/encyclopedia/tlpt **Last reviewed:** 2026-06-24 TLPT es el ejercicio de red team supervisado por el regulador que exige DORA a las entidades financieras significativas. Se basa en el marco TIBER-EU (Threat Intelligence-Based Ethical Red Teaming). De varios meses de duración, orientado por inteligencia y supervisado por la autoridad nacional. La prueba más rigurosa a la que se enfrentará un CISO, y la que expone al SOC tal como es realmente. ## Qué es realmente la prueba de penetración guiada por amenazas La prueba de penetración guiada por amenazas es un ejercicio controlado de red team contra una organización en plena producción, impulsado por inteligencia de amenazas real y supervisado por una autoridad financiera. El Digital Operational Resilience Act, DORA, la convierte en una obligación periódica para las entidades financieras que un regulador considera suficientemente significativas para justificarla, y el ejercicio se construye sobre TIBER-EU, el marco que el Banco Central Europeo publicó para el Threat Intelligence-Based Ethical Red Teaming. La palabra definitoria es guiada: la prueba no es una lista genérica de vulnerabilidades, sino una campaña moldeada por quién atacaría de forma realista a esta firma y cómo. Un proveedor de inteligencia de amenazas perfila a la entidad, identifica adversarios plausibles y sus métodos, y entrega al red team un conjunto de escenarios. El red team intenta entonces comprometer funciones críticas en producción usando esos escenarios, igual que lo haría un atacante real. Dos propiedades separan al TLPT de la prueba de penetración ordinaria. Primero, apunta al parque en producción real y a las personas y procesos que lo rodean, no a una copia ni a un segmento acotado, razón por la cual se ejecuta bajo reglas estrictas y con un pequeño equipo de control de confianza. Segundo, está supervisado. La autoridad nacional competente y, cuando corresponde, un equipo TIBER dedicado participan en el encargo, validando el alcance, acreditando a los testeadores y supervisando cómo se conduce el ejercicio. Esa supervisión es lo que hace que el resultado sea creíble para un regulador y no solo para la firma que lo encargó. ## Cómo se desarrolla un encargo TLPT Un TLPT es un programa de varios meses, no una evaluación de una semana, y se despliega en fases definidas que el marco TIBER-EU establece. En la fase de preparación, la entidad, el equipo de control y la autoridad acuerdan el alcance, confirman qué funciones críticas entran en juego y contratan proveedores acreditados de inteligencia de amenazas y de red team. En la fase de prueba, el proveedor de inteligencia produce un informe de objetivos sobre la entidad, y el red team lo usa para ejecutar escenarios de ataque realistas contra las funciones en producción, a menudo durante muchas semanas, intentando alcanzar objetivos definidos sin ser detenido. En la fase de cierre, el red team, el blue team y el equipo de control se reúnen para reconstruir lo ocurrido, acordar los hallazgos y construir un plan de remediación. El detalle crucial es que casi nadie dentro de la organización sabe que la prueba está ocurriendo. A los defensores, al centro de operaciones de seguridad y a los respondedores de incidentes no se les avisa, porque toda la finalidad es ver cómo se desempeñan frente a una intrusión real y no a un simulacro programado. Solo un equipo de control diminuto está al tanto. Esto es lo que convierte al TLPT en la medida más honesta de resiliencia operativa que un CISO encargará, y la que más fiablemente expone la brecha entre lo que se cree que hace el SOC y lo que realmente detecta bajo presión. > **El SOC es el verdadero sujeto de la prueba** Como a los defensores no se les avisa, un TLPT mide la detección y la respuesta tal como son de verdad, no tal como las describen los runbooks. Las alertas que nunca se afinaron, las rutas de escalado que nadie ensayó y los puntos ciegos en la cobertura afloran todos aquí. Trate la fase de cierre de purple teaming, donde el red y el blue reconstruyen juntos la campaña, como el resultado más valioso, no la brecha en sí. ## TLPT, TIBER-EU y la prueba de penetración ordinaria **Dónde se sitúa el TLPT respecto a los ejercicios vecinos** | Dimensión | Prueba de penetración estándar | Prueba de penetración guiada por amenazas (TLPT) | | --- | --- | --- | | Impulsor | Alcance predefinido y una lista de verificación del testeador | Inteligencia de amenazas a medida sobre la entidad concreta | | Objetivo | A menudo una copia de preproducción o una aplicación acotada | Funciones críticas en producción real y las personas que las rodean | | Conocimiento de los defensores | Por lo general informados, a veces colaborando | No informados, solo lo sabe un pequeño equipo de control | | Duración | De días a unas pocas semanas | Varios meses a lo largo de fases definidas | | Supervisión | Interna, encargada por la firma | Supervisada por la autoridad nacional bajo TIBER-EU | | Detonante | Discrecional o contractual | Una obligación de DORA para las entidades significativas designadas | Conviene mantener clara la relación entre los términos. TIBER-EU es el marco, la metodología y las fases. El TLPT es la obligación regulatoria bajo DORA que adopta y referencia ese marco para las entidades financieras dentro de su ámbito. Una prueba de penetración estándar sigue siendo una actividad valiosa y mucho más frecuente, pero responde a una pregunta más estrecha: ¿hay debilidades explotables en este sistema? Un TLPT responde a una más difícil: si un adversario realista fuese hoy a por nuestras funciones más importantes, ¿lo notaríamos siquiera, y podríamos responder? Ambas son complementarias, y una organización que espera un TLPT no deja de realizar pruebas ordinarias: las usa para cerrar las brechas evidentes de modo que el ejercicio guiado por amenazas pueda sondear las sutiles. Lo que los profesionales hacen realmente para prepararse rara vez consiste en comprar una herramienta más. Construyen un inventario exacto de las funciones críticas y de los sistemas que las sostienen, para que el alcance pueda acordarse con honestidad. Se aseguran de que los casos de uso de detección estén afinados y de que el SOC haya ensayado el escalado frente a escenarios realistas en lugar de ejercicios de mesa. Confirman la estructura del equipo de control y las aprobaciones legales y de riesgo necesarias para ejecutar con seguridad una intrusión contra producción. Y tratan los hallazgos como insumo para la resiliencia operativa y la planificación de continuidad, porque bajo DORA la remediación no es un informe privado: es evidencia sobre la que el regulador espera que se actúe. --- ## Ransomware **URL:** https://cyberacademy.net/es/resources/encyclopedia/ransomware **Last reviewed:** 2026-06-24 El ransomware es la clase de malware que cifra datos y exige un pago a cambio de la clave, frecuentemente combinado con robo de datos y extorsión (doble extorsión). Vectores de ataque: phishing, exposición de servicios a internet, cadena de suministro. Los seguros cubren menos y los reguladores supervisan más. El trabajo previo al incidente (copias de seguridad, segmentación, plan de respuesta) determina el resultado, no la negociación. ## Qué es realmente un ransomware, y por qué el cifrado es la parte fácil Un ransomware es un software malicioso que se apodera de algo que necesitas y te obliga a pagar para recuperarlo. El mecanismo clásico es el cifrado: el malware codifica los archivos de los sistemas a los que llega y ofrece la clave de descifrado a cambio de un pago, normalmente en criptomoneda. Pero tratar el ransomware como un problema de cifrado ignora lo que lo hace tan dañino. El cifrado es el síntoma visible de una intrusión que a menudo lleva días o semanas en marcha. Antes de que se bloquee un solo archivo, un atacante suele haber conseguido un acceso inicial, escalado privilegios, desplazado lateralmente por la red, localizado los sistemas que importan y, con frecuencia, copiado los datos hacia el exterior. El bloqueo final es simplemente el momento en que el operador decide convertir ese acceso en dinero. Esa secuencia explica por qué los peores incidentes de ransomware ya no se limitan a archivos cifrados. Los operadores aprendieron que una víctima con buenas copias de seguridad podía negarse a pagar y restaurar, así que añadieron una segunda palanca: robar primero los datos y luego amenazar con publicarlos. Esto es la doble extorsión, y cambia por completo el cálculo. Incluso una organización que restaura limpiamente desde una copia de seguridad sigue enfrentándose a la posibilidad de que datos confidenciales, registros de clientes o contratos se filtren en un sitio público. Algunos grupos van más allá con presiones adicionales, contactando directamente con clientes o reguladores, o añadiendo un ataque de denegación de servicio. La negociación, cuando la hay, no trata realmente sobre una clave de descifrado. Trata sobre si los datos robados permanecen privados. ## Cómo entra, y por qué al regulador ahora le importa La vía de entrada rara vez es exótica. Los vectores dominantes son los más anodinos: un correo de phishing que entrega un loader o recolecta credenciales, un servicio expuesto a Internet sin protección o sin parchear, una contraseña de acceso remoto débil o reutilizada, y la cadena de suministro, donde un proveedor o software de confianza se convierte en la vía hacia tu red. Nada de esto requiere un exploit novedoso. Basta con una puerta abierta, y por eso la gestión de la exposición y la higiene de identidad reducen más el riesgo de ransomware que cualquier producto aislado. Un incidente de ransomware es ahora un evento regulatorio, no solo técnico. Como el ataque casi siempre implica robo de datos, suele activar las obligaciones de violación de datos personales del GDPR, lo que conlleva una evaluación de notificación a la autoridad de control y, en casos graves, a las personas afectadas. Los operadores de servicios esenciales e importantes se enfrentan a deberes de notificación de incidentes que se solapan bajo la directiva NIS2. Agencias nacionales como ANSSI y ENISA publican guías precisamente porque el mismo modus operandi sigue funcionando. La consecuencia práctica para una función de riesgo es que el plan de respuesta debe incluir la vía jurídica y de notificación desde la primera hora, ejecutada en paralelo a la recuperación técnica, y no añadida a posteriori. > **Pagar no cierra el caso** Un pago puede producir una clave de descifrado, pero no deshace una violación de datos. El plazo de notificación del GDPR sigue corriendo, los datos robados aún pueden filtrarse y los reguladores examinan con lupa los pagos a entidades sancionadas. Trata cualquier decisión de pago como una decisión jurídica y de riesgo tomada con asesoramiento legal, nunca como la solución técnica. ## El desenlace se decide antes del ataque, no durante la nota de rescate La idea más importante para los profesionales es que el resultado de un incidente de ransomware viene determinado en gran medida por el trabajo realizado mucho antes de que ocurra. Una organización capaz de restaurar rápidamente desde copias de seguridad limpias, probadas, sin conexión o inmutables puede negarse a pagar por una clave. Aquella cuyas copias de seguridad eran accesibles desde la misma red, y por tanto se cifraron junto con todo lo demás, no tiene esa opción. La segmentación de la red limita hasta dónde puede propagarse una intrusión antes de alcanzar los sistemas que importan. Una autenticación fuerte en el acceso remoto y el correo cierra las puertas de entrada más comunes. Una detección que capta el movimiento lateral gana las horas que separan un incidente contenido de un evento de cifrado a escala de toda la empresa. Lo que hacen realmente los equipos competentes, por tanto, es invertir en la postura previa al incidente en lugar de en la habilidad de negociación. Mantienen copias de seguridad aisladas del dominio de producción, cifradas en reposo y restauradas según un calendario, de modo que la recuperación quede demostrada y no solo supuesta. Segmentan las redes para que una estación de trabajo comprometida no pueda alcanzar sin obstáculos el servidor de copias de seguridad o los controladores de dominio. Mantienen un plan de respuesta a incidentes que designa funciones, responsables de decisión, expertos forenses externos y asesoría jurídica, así como la vía de notificación, y lo ensayan. Aquí es donde el ransomware se conecta directamente con la gestión de la continuidad del negocio y la recuperación ante desastres: el tiempo de recuperación y el punto de recuperación que una organización puede alcanzar realmente, probados frente a un escenario realista, marcan la diferencia entre una mala semana y una crisis existencial. --- ## Registro de Actividades de Tratamiento (ROPA) **URL:** https://cyberacademy.net/es/resources/encyclopedia/ropa **Last reviewed:** 2026-06-24 El ROPA es el inventario documentado de actividades de tratamiento exigido por el artículo 30 del GDPR. Los responsables consignan finalidad, categorías, destinatarios, plazos de conservación y transferencias; los encargados, los responsables a quienes sirven, las categorías y las transferencias. La mayoría de las organizaciones subestima el trabajo de mantenimiento. La autoridad de control solicita el ROPA en primer lugar cuando se abre una investigación. ## Qué es realmente el ROPA (registro de actividades de tratamiento) El registro de actividades de tratamiento es el mapa de todo lo que una organización hace con datos personales. No es una política ni una promesa; es un inventario, mantenido al día, que permite responder a una pregunta sencilla para cualquier operación de tratamiento: qué datos, con qué finalidad, sobre qué base jurídica, quién accede a ellos, adónde van y cuánto tiempo se conservan. El GDPR convierte este registro en una obligación en virtud del artículo 30, y reparte el deber según el rol. Un responsable del tratamiento documenta sus propias actividades de tratamiento; un encargado del tratamiento documenta las categorías de tratamiento que lleva a cabo por cuenta de los responsables a los que presta servicio. Los dos registros se solapan, pero no son lo mismo, y una organización que actúa a la vez como responsable y como encargado debe mantener ambos. En la práctica, el ROPA es el cimiento sobre el que se sostiene el resto de un programa de privacidad. No se puede llevar a cabo una EIPD significativa, responder a una solicitud de acceso de un interesado, delimitar una brecha o negociar un contrato de encargo de tratamiento sin saber primero que el tratamiento existe y dónde residen los datos. Por eso la autoridad de control pide el ROPA en primer lugar cuando se abre una investigación. Es la forma más rápida que tiene un regulador de calibrar si una organización entiende realmente sus propios datos, y un registro pobre o desactualizado indica que el resto del programa probablemente también lo esté. ## Qué contiene: responsable frente a encargado Las dos versiones del registro incluyen campos distintos porque los dos roles responden a preguntas distintas. Un responsable del tratamiento decide por qué y cómo se tratan los datos, de modo que su registro debe justificar cada finalidad. Un encargado solo actúa siguiendo instrucciones, de modo que su registro describe el servicio que presta, no la razón que lo motiva. **Registro del responsable frente a registro del encargado** | Elemento | Registro del responsable | Registro del encargado | | --- | --- | --- | | Identidad y contacto | Responsable, posibles corresponsables, representante, DPO | Encargado, representante, DPO, y cada responsable al que presta servicio | | Finalidades | Finalidad de cada actividad de tratamiento | No exigido; el encargado actúa siguiendo instrucciones | | Interesados y categorías | Categorías de personas y de datos personales | Categorías de tratamiento realizadas por cada responsable | | Destinatarios | A quién se comunican los datos | Ídem, cuando sea pertinente para el servicio | | Transferencias | Transferencias fuera de la UE y garantías utilizadas | Transferencias fuera de la UE y garantías utilizadas | | Conservación | Plazos previstos para la supresión cuando sea posible | No exigido por separado | | Seguridad | Descripción general de las medidas técnicas y organizativas | Descripción general de las medidas técnicas y organizativas | Los campos parecen administrativos, pero cada uno soporta carga. Los plazos de conservación impulsan tus flujos de supresión. Las listas de destinatarios alimentan tu inventario de encargados y tus evaluaciones de impacto de las transferencias. Las categorías de datos señalan dónde un tratamiento de categorías especiales activa la obligación de un DPO o de una EIPD. Cumplimentado con honestidad, el ROPA es una herramienta de diagnóstico operativa; cumplimentado como un mero trámite de marcar casillas, es peor que inútil porque da una falsa garantía. > **El mantenimiento es la parte difícil** La mayoría de las organizaciones subestiman el mantenimiento. Construir el primer ROPA es un proyecto con un final claro; mantenerlo exacto es un proceso sin fin. Nuevas herramientas, nuevos proveedores, nuevas campañas de marketing y reorganizaciones cambian todos el panorama del tratamiento, y un registro que estaba completo en la auditoría se desactualiza en cuestión de meses. La solución consiste en vincular las actualizaciones del ROPA a eventos de cambio existentes, la incorporación de un proveedor, el lanzamiento de una funcionalidad, la firma de un contrato de encargo, en lugar de depender de una revisión anual que nadie asume. ## Quién debe mantenerlo y cómo se conecta El GDPR formula el deber del artículo 30 con una exención para las organizaciones de menos de 250 empleados, pero la exención es lo bastante estrecha como para que la mayoría siga necesitando un registro. Decae en cuanto el tratamiento no es ocasional, es probable que entrañe un riesgo para las personas, o implica datos de categorías especiales o relativos a infracciones penales, lo que abarca el tratamiento habitual de casi cualquier empresa en funcionamiento. Las autoridades de control, incluida la CNIL, tratan el ROPA como una práctica esperada y no como una obligación poco frecuente, y la CNIL publica una plantilla gratuita para reducir la barrera de entrada. El registro no vive solo. Es la columna vertebral a la que se anclan la EIPD, la función de DPO y el proceso de respuesta a brechas. El DPO lo utiliza para supervisar el cumplimiento y asesorar sobre el riesgo; una EIPD empieza extrayendo la entrada pertinente; una evaluación de brecha lo usa para delimitar qué datos y qué personas están en juego. Las organizaciones que avanzan hacia ISO 27701 reconocerán el ROPA como, en esencia, el sistema de gestión de la información de privacidad pidiendo el mismo inventario, razón por la cual los equipos maduros mantienen un único registro y dejan que sirva a varios regímenes en lugar de mantener listas paralelas. --- ## Registro de riesgos **URL:** https://cyberacademy.net/es/resources/encyclopedia/risk-register **Last reviewed:** 2026-06-24 El registro de riesgos es la lista canónica y viva de riesgos identificados, con su análisis, evaluación, tratamiento y responsable. No es una hoja de cálculo puntual. Los auditores esperan entradas fechadas, propietarios nominados, cambios trazables y ciclos de revisión vinculados a la revisión por la dirección. La versión para el consejo es más corta; la versión operativa contiene todo. ## Qué es realmente el registro El registro de riesgos es el único lugar donde la organización lleva el seguimiento de lo que le preocupa y de lo que hace al respecto. La gente imagina una hoja de cálculo, y a menudo empieza siéndolo, pero el artefacto que importa es la disciplina que lo sustenta : cada riesgo identificado, analizado, evaluado frente al apetito, asignado a un propietario, dotado de una decisión de tratamiento y revisado según un ciclo. Un registro rellenado una sola vez para una certificación y nunca vuelto a tocar no es un registro de riesgos, es una pieza de museo. La prueba consiste en saber si puedes mirar cualquier línea y ver cuándo se revisó por última vez, quién es su propietario y qué ha cambiado desde entonces. Cada entrada suele incluir una descripción del riesgo, el activo u objetivo que amenaza, el análisis (probabilidad e impacto, sea cual sea la forma en que los puntúes), la evaluación frente a tus criterios, el tratamiento elegido, el propietario designado, el riesgo residual tras el tratamiento y una fecha de revisión. El nivel de detalle es deliberado : cuando un auditor o un incidente tira de un hilo, la entrada tiene que aguantar. Las entradas vagas, sin propietario ni fecha, son lo primero que detecta un auditor competente, y socavan la credibilidad de todo el programa. ## Cómo se conecta con todo lo demás El registro no es un documento independiente, es el eje al que se conecta el resto del programa de riesgos. La identificación y el análisis siguen una metodología como ISO 27005 o EBIOS RM, y su resultado aterriza aquí. La columna de tratamiento es donde cada riesgo se encuentra con la decisión de evitar, reducir, transferir o aceptar, y en un contexto ISO 27001 esa decisión se prolonga hasta la Declaración de Aplicabilidad y los controles que la implementan. La columna de evaluación solo significa algo si existe un apetito de riesgo escrito frente al cual evaluar, de lo contrario cada valoración no es más que la opinión de un analista. Así pues, el registro se sitúa aguas abajo de la metodología y del apetito, y aguas arriba del tratamiento y de la evidencia de los controles. Por eso también el registro es un documento vivo ligado a la revisión por la dirección y no un entregable puntual. Aparecen riesgos nuevos, los riesgos tratados cambian su valoración residual, los propietarios se marchan, y el propio apetito puede variar. Un programa maduro revisa el registro con una cadencia definida y traslada los movimientos significativos a la revisión por la dirección, de modo que el liderazgo tome decisiones sobre una imagen actual y no sobre la del año pasado. > **Dos audiencias, dos versiones** El registro operativo lo contiene todo : cada entrada, cada campo, cada propietario. La versión que llega al consejo es un resumen deliberado de los riesgos que importan a su altura. Intentar que un solo documento sirva para ambos es un error común. El consejo se ahoga en un detalle sobre el que no puede actuar, y el equipo operativo pierde su herramienta de trabajo. Mantén ambos, y mantenlos conciliados. ## Qué mantienen realmente los profesionales En la práctica el registro es donde las buenas intenciones se encuentran con el mantenimiento. Lo difícil no es la primera pasada, es mantenerlo honesto a lo largo de los años. Las entradas fechadas importan porque un auditor espera ver un cambio trazable : cuándo se planteó un riesgo, cuándo se movió su valoración, cuándo se completó el tratamiento. Los propietarios designados importan porque un riesgo sin propietario es un riesgo que en realidad nadie gestiona. Los ciclos de revisión importan porque las tolerancias y las dependencias se desplazan, y un registro con dos reorganizaciones de antigüedad priorizará lo equivocado. Los campos son fáciles de enumerar y difíciles de sostener, que es precisamente por lo que el registro, y no la política, es donde se ve si un programa de riesgos está vivo. Una confusión frecuente es entre el registro y el plan de tratamiento. El registro es el inventario de los riesgos y de su estado actual. El plan de tratamiento es el conjunto de acciones a las que te has comprometido, con plazos y responsabilidad, para llevar los riesgos hacia niveles aceptables. Se referencian mutuamente pero no son el mismo documento, y cuando se separan la auditoría lo nota. Mantén el registro como la fuente de verdad del estado, y deja que el plan de tratamiento sea la fuente de verdad del trabajo en curso. --- ## Reglamento General de Protección de Datos (GDPR) **URL:** https://cyberacademy.net/es/resources/encyclopedia/gdpr **Last reviewed:** 2026-06-24 El GDPR regula los datos personales en la UE y en cualquier ámbito que atienda a residentes europeos. Base jurídica, derechos de los interesados, responsabilidad proactiva, notificación de brechas, supervisión y sanciones. Las multas máximas (20 millones de euros o el 4% de la facturación mundial anual) acaparan titulares; la mayoría de las actuaciones de control se resuelven a través del diálogo con la autoridad supervisora, no mediante el máximo legal. ## Un reglamento sobre responsabilidad proactiva, no solo sobre consentimiento El RGPD suele reducirse, en las conversaciones, a los avisos de cookies y a las ventanas emergentes de consentimiento, pero esa imagen pasa por alto dónde reside realmente su peso. El consentimiento es solo una de las varias bases jurídicas para el tratamiento de datos personales y, para la mayoría de las operaciones de una organización, ni siquiera es aquella en la que se apoya. La ejecución de un contrato, la obligación legal y el interés legítimo soportan, en la práctica, muchos más tratamientos. El cambio más profundo que introdujo el RGPD es la responsabilidad proactiva (accountability): no basta con cumplir, hay que poder demostrar el cumplimiento. Ese único principio es lo que transforma la protección de datos, que pasa de ser una opinión jurídica a una disciplina operativa, con registros, evaluaciones y pruebas detrás de cada afirmación. Por tratarse de un reglamento y no de una directiva, el RGPD se aplica directamente en toda la UE y, más ampliamente, en el EEE, sin que cada país tenga que transponerlo a su derecho nacional, razón por la que sus obligaciones fundamentales son idénticas en Francia, Alemania e Irlanda. Su alcance también se extiende más allá de Europa. Una organización establecida fuera de la UE sigue entrando en su ámbito de aplicación cuando ofrece bienes o servicios a personas que se encuentran en la Unión o cuando controla su comportamiento en dicho territorio. Este alcance territorial explica que una empresa sin oficina europea pueda, aun así, tener que responder ante una autoridad de control europea. ## Base jurídica, derechos de los interesados y deberes que de ellos se derivan Todo tratamiento de datos personales necesita una base jurídica elegida antes de que comience el tratamiento, y la base que se escoja determina los derechos que las personas pueden ejercer. Los interesados pueden solicitar acceder a sus datos, que se rectifiquen o supriman, limitar el tratamiento u oponerse a él y, en algunos casos, recibirlos en un formato portátil. Ninguno de estos derechos es absoluto; cada uno conlleva condiciones y excepciones. En torno a los derechos se sitúan los deberes del responsable y del encargado del tratamiento: protección de datos desde el diseño y por defecto, llevar un registro de las actividades de tratamiento, proteger los datos con medidas técnicas y organizativas apropiadas, y establecer contratos por escrito siempre que un encargado trate datos por cuenta de un responsable. Dos deberes merecen destacarse porque rigen el trabajo del día a día. Cuando es probable que un tratamiento entrañe un alto riesgo para las personas, el responsable lleva a cabo una evaluación de impacto relativa a la protección de datos antes de seguir adelante, documentando el riesgo y la forma de mitigarlo. Y cuando se produce una violación de la seguridad de los datos personales, el responsable se enfrenta a un deber de notificación ante la autoridad de control dentro de un plazo corto y definido, informando también a las personas afectadas cuando el riesgo para ellas es alto. No son rituales de papeleo. Son los puntos en los que el principio de responsabilidad proactiva se convierte en una obligación concreta y sujeta a plazos. > **El RGPD fija la ley, ISO 27701 le ayuda a aplicarla** El RGPD le dice qué debe lograr, pero no cómo operarlo como un sistema. ISO/IEC 27701 amplía un sistema de gestión de la seguridad de la información ISO 27001 hasta convertirlo en un sistema de gestión de la información de privacidad, ofreciéndole rutinas repetibles para los registros, las evaluaciones y los controles que el reglamento espera. La certificación no equivale al cumplimiento legal, pero hace que ese cumplimiento sea auditable en lugar de improvisado. ## Dónde se sitúa el RGPD entre los conceptos vecinos Conviene separar el RGPD de los roles y las herramientas que orbitan a su alrededor. Un DPO es una persona o función que algunas organizaciones deben designar para supervisar el cumplimiento; una DPIA es el proceso de evaluación para los tratamientos de alto riesgo; un ROPA es el inventario de las actividades de tratamiento; las cláusulas contractuales tipo son uno de los mecanismos para transferir datos fuera de la UE de forma lícita. El RGPD es el reglamento que exige o habilita cada uno de estos elementos. Las autoridades de control nacionales, como la CNIL en Francia, lo aplican y emiten directrices, y el Comité Europeo de Protección de Datos las coordina para que una interpretación única se mantenga a través de las fronteras. Como señala la shortDefinition, las cifras destacadas de hasta 20 millones de euros o el 4 por ciento del volumen de negocios anual mundial dominan la cobertura de prensa, y sin embargo la mayor parte de la aplicación de la norma transcurre a través del diálogo con la autoridad de control en lugar de mediante multas máximas. Las autoridades investigan, formulan preguntas, exigen subsanaciones y a menudo resuelven los asuntos mediante medidas correctivas muy por debajo del límite máximo. Para los profesionales, la lección práctica es que una buena fe demostrable y una postura de cumplimiento respaldada por pruebas cambian el rumbo de ese diálogo. Las organizaciones que peor salen paradas suelen ser las que no pueden demostrar qué hacían con los datos, no las que tomaron una decisión honesta y documentada. ## Cómo lo ponen en práctica los profesionales Convertir el reglamento en trabajo rutinario suele empezar por la cartografía. Se construye y mantiene un registro de las actividades de tratamiento para saber qué datos se poseen, por qué, sobre qué base jurídica y hacia dónde fluyen. A partir de ahí, los equipos integran la privacidad desde el diseño en los nuevos proyectos, realizan DPIA allí donde el riesgo es alto, refuerzan los contratos con los encargados y ensayan el recorrido de notificación de violaciones para que el reloj no los pille desprevenidos. Muchos anclan esto en un sistema de gestión en lugar de en una carpeta de políticas, que es donde normas como ISO 27701 y las directrices de apoyo de las autoridades de control se ganan su lugar. El objetivo es una prueba en régimen permanente: en cualquier momento se puede demostrar una base jurídica, un registro y un control para los datos personales que se tratan. --- ## Riesgo inherente vs. riesgo residual **URL:** https://cyberacademy.net/es/resources/encyclopedia/inherent-residual-risk **Last reviewed:** 2026-06-24 El riesgo inherente es la exposición antes de los controles. El riesgo residual es lo que queda tras la operación de dichos controles. Los auditores analizan la brecha: debe estar justificada, aceptada (o tratada de forma adicional) por un responsable nombrado, y coherente con el apetito de riesgo. Que aparezca «residual = cero» en cualquier punto del registro es una señal de alerta, no un logro. ## El mismo riesgo visto en dos momentos El riesgo inherente y el riesgo residual no son dos riesgos diferentes. Son el mismo escenario medido en dos puntos: antes de que tus controles realicen su trabajo y después de que lo hayan hecho. El riesgo inherente es la exposición en bruto, el nivel de probabilidad e impacto al que te enfrentarías si los controles pertinentes estuvieran ausentes o fallaran por completo. El riesgo residual es lo que queda una vez que los controles están implantados y operan según lo previsto. Leerlos uno junto al otro es todo el sentido del ejercicio, porque la brecha entre ambos es el valor visible de tu entorno de control. Una brecha amplia indica que los controles cumplen su función; una brecha estrecha indica que estás invirtiendo esfuerzo para una reducción escasa y deberías preguntarte por qué. Tratar estos niveles como un par cambia tu forma de gastar. Si dos escenarios comparten un nivel residual similar pero uno partía de un nivel inherente mucho más alto, el conjunto de controles que lo mantiene bajo realiza un trabajo considerable y merece protección en el presupuesto. El escenario que apenas se movió de lo inherente a lo residual es el que hay que revisar: o el control es débil, o es el control equivocado, o el riesgo nunca estuvo tan expuesto como afirmaba la valoración. **Riesgo inherente frente a riesgo residual** | Dimensión | Riesgo inherente | Riesgo residual | | --- | --- | --- | | Cuándo se mide | Antes de los controles | Después de que operan los controles | | Qué muestra | Exposición en bruto del escenario | Exposición que realmente permanece | | Uso principal | Priorizar dónde se necesitan controles | Decidir aceptar, tratar más o transferir | | Comparado con | Otros escenarios sin tratar | El apetito y la tolerancia al riesgo | | Acción del propietario | Diseñar el tratamiento | Aceptar y firmar, o escalar la brecha | ## Qué esperan los auditores y las normas La brecha entre lo inherente y lo residual es donde reside el aseguramiento, así que debe justificarse en lugar de afirmarse. Un auditor lee el registro y exige tres cosas a cada cifra residual: qué controles la redujeron, si esos controles operan genuinamente en lugar de solo estar documentados, y quién aceptó lo que queda. Ese último punto importa. El riesgo residual lo acepta un propietario nombrado con la autoridad para asumirlo, y esa aceptación debe situarse dentro del apetito de riesgo de la organización. Un nivel residual que supera el apetito no es una entrada terminada; es un punto abierto que exige tratamiento adicional, transferencia, o una excepción deliberada y documentada. Esta lógica está incorporada en los principales marcos. ISO 31000 plantea la gestión del riesgo como un bucle iterativo en el que el tratamiento modifica el riesgo y el riesgo modificado se vuelve a evaluar, que es exactamente el paso de lo inherente a lo residual. ISO/IEC 27005 aplica el mismo razonamiento al riesgo de seguridad de la información y es explícita en que el riesgo residual debe evaluarse y ser aceptado formalmente por la dirección antes de que un sistema entre en funcionamiento o permanezca en producción. Las directrices del NIST sobre la evaluación de riesgos mantienen la distinción idéntica entre el riesgo al que se enfrenta una organización y la porción que permanece tras aplicar las respuestas. Ninguna de estas normas trata lo residual como un número que se calcula una vez y se archiva. > **Un residual cero es una señal de alarma, no un trofeo** Un registro que muestra el riesgo residual reducido a cero casi siempre está equivocado, porque ningún conjunto de controles es perfecto y los propios controles fallan. Cero suele significar que alguien confundió el objetivo con la realidad, o que dejó de contabilizar discretamente el fallo de los controles. Los auditores lo leen como un problema de madurez, no como un éxito. ## Hacerlo bien en la práctica En un registro operativo, cada línea debería permitir a un lector rastrear la valoración inherente, los controles aplicados, la valoración residual, y el propietario nombrado que la aceptó. Mantén el método de valoración coherente entre lo inherente y lo residual para que ambos sean genuinamente comparables; si puntúas el impacto y la probabilidad de forma distinta en cada etapa, la brecha no significa nada. Vuelve a valorar lo residual siempre que un control cambie, se degrade, o se revele ineficaz durante las pruebas, porque el riesgo residual solo está tan actualizado como los controles que lo sustentan. Una cifra residual fijada hace dos auditorías y nunca revisada es decoración, no aseguramiento. El juicio que aporta valor consiste en vincular el riesgo residual con el apetito y el tratamiento. Una vez que lo residual se sitúa en el apetito o por debajo, la aceptación es razonable y el propietario firma. Cuando se sitúa por encima, la entrada honesta registra la brecha y el plan para cerrarla, en lugar de redondear el número hacia abajo para que la página parezca ordenada. Esa disciplina es lo que convierte un registro, de artefacto de cumplimiento, en una herramienta que el consejo puede utilizar realmente para asignar atención. --- ## SOC 2 **URL:** https://cyberacademy.net/es/resources/encyclopedia/soc-2 **Last reviewed:** 2026-06-24 SOC 2 es el informe de atestación de la AICPA sobre los controles de una organización de servicios, que abarca cinco criterios de confianza (seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad). Es el estándar canónico norteamericano para proveedores SaaS; ISO 27001 es su equivalente europeo. Tipo I = momento puntual; Tipo II = eficacia operativa durante 6 a 12 meses. Frecuentemente exigido en procesos de compra empresarial. ## Qué acredita realmente SOC 2 SOC 2 no es una certificación que se apruebe o se suspenda. Es un informe de atestación elaborado por una firma de CPA con licencia conforme a las normas de atestación de la AICPA, en el que un auditor independiente expresa una opinión sobre si los controles de una organización de servicios están diseñados de forma adecuada y, para el Tipo II, funcionan eficazmente durante un periodo. El alcance se construye en torno a los Trust Services Criteria: seguridad (la única categoría obligatoria, también llamada common criteria), disponibilidad, integridad de procesamiento, confidencialidad y privacidad. Usted elige cuáles de los cinco se aplican al servicio que ofrece, y el informe se dimensiona según esa elección. Dado que es una opinión sobre una descripción que redacta la dirección, dos informes SOC 2 rara vez son idénticos. Un proveedor puede limitar el alcance solo a la seguridad; otro puede añadir disponibilidad y confidencialidad. Leer el informe significa leer la descripción del sistema, los criterios incluidos en el alcance, las pruebas realizadas y, sobre todo, cualquier excepción que el auditor haya señalado. Un informe sin salvedades con un alcance ajustado puede ser una evidencia más débil que un informe con excepciones menores en un alcance amplio. ## Tipo I frente al Tipo II La distinción que más importa a los profesionales es la del Tipo I frente al Tipo II. El Tipo I es una instantánea: el auditor opina que los controles están diseñados de forma adecuada en una única fecha. Demuestra que los controles existen sobre el papel y estaban implantados ese día. El Tipo II es el que realmente quieren los compradores corporativos, porque el auditor comprueba si esos controles funcionaron eficazmente durante un periodo de revisión que suele abarcar de seis a doce meses, muestreando evidencia a lo largo del mismo. Un Tipo II responde a la verdadera pregunta de compras: ¿hizo el proveedor esto de forma constante, y no solo el día de la auditoría? **SOC 2 Tipo I vs Tipo II** | Dimensión | Tipo I | Tipo II | | --- | --- | --- | | Qué se prueba | Diseño de los controles | Diseño y eficacia operativa | | Marco temporal | Un único momento en el tiempo | Un periodo de revisión (habitualmente de 6 a 12 meses) | | Evidencia | Controles implantados en la fecha | Evidencia muestreada a lo largo del periodo | | Uso típico | Primer informe, proveedores en fase inicial | Lo que esperan las compras corporativas | ## SOC 2 junto a ISO 27001 SOC 2 e ISO 27001 responden a la misma preocupación del comprador desde dos tradiciones. SOC 2 es la señal canónica norteamericana, una atestación de auditor vinculada a los Trust Services Criteria y renovada según un periodo recurrente. ISO 27001 es la norma internacional y certificable construida en torno a un sistema de gestión (el SGSI), con la certificación emitida por un organismo acreditado y mantenida mediante auditorías de seguimiento. SOC 2 informa sobre los controles frente a criterios; ISO 27001 certifica que usted opera un sistema en funcionamiento con una Declaración de Aplicabilidad y mejora continua. Muchos proveedores que venden a ambos lados del Atlántico acaban teniendo ambos, y la evidencia de control se solapa en gran medida aunque los entregables difieran. En la práctica, los equipos de GRC tratan ambos como complementarios en lugar de competidores. Los mismos controles de acceso, la gestión de cambios, el tratamiento de vulnerabilidades y la respuesta a incidentes alimentan tanto el conjunto de controles del Anexo A de ISO 27001 como los common criteria de SOC 2. El trabajo consiste en mapear una vez y presentar dos veces. > **Lea el informe, no el logotipo** Un distintivo SOC 2 no le dice casi nada por sí solo. Solicite siempre el informe completo y compruebe los criterios incluidos en el alcance, si es Tipo I o Tipo II, el periodo cubierto, las organizaciones de subservicios excluidas y cualquier excepción señalada. --- ## Schrems II **URL:** https://cyberacademy.net/es/resources/encyclopedia/schrems-ii **Last reviewed:** 2026-06-24 Schrems II es la sentencia del TJUE de 2020 que anuló el EU-US Privacy Shield e introdujo el requisito de la Evaluación de Impacto de la Transferencia (TIA). Cada transferencia a un tercer país requiere ahora un análisis documentado de la legislación local en materia de vigilancia y de las medidas suplementarias aplicables. En la práctica fue sustituido por el EU-US Data Privacy Framework (2023), pero la disciplina de la TIA se consolidó. ## Lo que la sentencia decidió realmente Schrems II es la sentencia del Tribunal de Justicia de la Unión Europea, dictada en julio de 2020 en el asunto Data Protection Commissioner v Facebook Ireland y Maximillian Schrems, que reconfiguró la forma en que los datos personales salen del Espacio Económico Europeo. Ocurrieron dos cosas a la vez. Primero, el Tribunal invalidó el Privacy Shield UE-EE. UU., el acuerdo de adecuación que había permitido a miles de empresas transferir datos a importadores estadounidenses certificados, porque la legislación de vigilancia de EE. UU. no ofrecía a las personas de la Unión una protección esencialmente equivalente a la garantizada dentro de la Unión, y no les concedía ninguna tutela judicial efectiva. Segundo, y esta es la parte que perdura, el Tribunal no anuló las cláusulas contractuales tipo. Las mantuvo válidas, pero añadió una condición: el exportador no puede limitarse a firmar las cláusulas y desentenderse. Esa condición es el meollo del asunto. El Tribunal afirmó que los exportadores de datos deben verificar, caso por caso, si el derecho y la práctica del país de destino permiten realmente al importador respetar las garantías contractuales. Cuando no es así, el exportador tiene que añadir medidas adicionales o detener la transferencia. El contrato por sí solo no basta si un gobierno extranjero puede imponer el acceso de una forma que las cláusulas no pueden impedir. ## La evaluación de impacto de la transferencia en la práctica La disciplina que creó Schrems II es la evaluación de impacto de la transferencia, o TIA. Es el análisis documentado que convierte la sentencia en un control repetible. Un profesional que realiza una TIA recorre una secuencia reconocible en lugar de un dictamen jurídico aislado. - Cartografiar la transferencia. Identificar qué datos van a dónde, las categorías de personas afectadas, el importador, cualquier transferencia ulterior y el mecanismo jurídico en el que se apoya, normalmente las SCC. - Evaluar el derecho y la práctica de destino. Examinar el régimen de vigilancia y de acceso gubernamental en el país importador y juzgar si socava la protección que se supone que debe proporcionar la herramienta de transferencia. Este es el análisis del derecho de vigilancia que exigió el Tribunal. - Identificar las medidas adicionales. Cuando el derecho local resulta problemático, decidir qué garantías técnicas, contractuales u organizativas adicionales cierran la brecha. El cifrado robusto con claves conservadas únicamente en el EEE, la seudonimización y el procesamiento fraccionado son las medidas técnicas que más señalan los reguladores. - Documentar y decidir. Registrar el razonamiento, concluir si la transferencia puede continuar y establecer un desencadenante de revisión para que la evaluación se reexamine cuando cambie el derecho o el acuerdo. > **La TIA sobrevivió al asunto que la creó** Schrems II se describe a menudo como un asunto sobre el Privacy Shield, pero su legado duradero es el hábito de la evaluación. Incluso ahora que el Data Privacy Framework UE-EE. UU. ofrece una nueva vía de adecuación para Estados Unidos, la obligación de evaluar el destino, elegir un mecanismo lícito y documentar las medidas adicionales se aplica a todo tercer país. La TIA es ya un elemento estándar en cualquier programa de privacidad, no una reacción puntual. ## Dónde se sitúa hoy En 2023 la Comisión Europea adoptó el Data Privacy Framework UE-EE. UU., una nueva decisión de adecuación que, para las organizaciones estadounidenses certificadas, restablece una vía para transferir datos sin TIA en ese corredor concreto. Se diseñó para responder a las inquietudes sobre la tutela y la proporcionalidad que hundieron el Privacy Shield, incluido un mecanismo de revisión independiente para las personas de la Unión. Así, en términos cotidianos, la brecha del Privacy Shield que abrió Schrems II se ha salvado para Estados Unidos, siempre que el importador esté certificado conforme al nuevo marco y la transferencia permanezca dentro de su ámbito. Lo que no desapareció es el método más amplio. Las transferencias a países sin decisión de adecuación siguen basándose en las SCC u otras herramientas del artículo 46, y cada una de ellas todavía necesita una TIA. Las directrices del Comité Europeo de Protección de Datos sobre las medidas adicionales siguen siendo el manual práctico. Por tanto, la forma correcta de leer Schrems II en 2026 no es como una historia muerta del Privacy Shield, sino como el momento en que el riesgo de transferencia pasó a ser algo que se evalúa y se documenta, transferencia por transferencia, en lugar de descartarlo marcando una casilla de adecuación. Conviene mantener distintos dos conceptos vecinos. Una decisión de adecuación es la Comisión afirmando que todo un país ofrece una protección equivalente, lo que elimina la necesidad de garantías adicionales. Las SCC son una herramienta contractual que se utiliza cuando no hay decisión de adecuación, y Schrems II es precisamente la sentencia que dijo que las SCC vienen con la tarea adjunta de una TIA. --- ## Security Operations Center (SOC) **URL:** https://cyberacademy.net/es/resources/encyclopedia/soc **Last reviewed:** 2026-06-24 Un SOC es el equipo y el conjunto de herramientas que monitoriza, detecta, analiza y responde a eventos de seguridad en tiempo real. Analistas por niveles (T1 detección, T2 investigación, T3 threat hunting), 8x5 o 24x7. Interno, externalizado (MSSP) o híbrido. Sin un SOC, el SIEM es un archivo de logs; con uno, es un sistema de alerta temprana. ## Lo que realmente hace un SOC Un Security Operations Center es la función que convierte la telemetría en bruto en decisiones y acciones. La shortDefinition lo presenta como el equipo más el conjunto de herramientas; en la práctica, el valor reside en el modelo operativo que los conecta. El SIEM recopila y correlaciona registros, el EDR registra el comportamiento de los endpoints y el SOAR ejecuta playbooks, pero nada de eso produce seguridad por sí solo. El SOC es lo que lee la alerta a las 02:00, decide si se trata de un falso positivo o de la primera señal de una intrusión, y acciona la palanca adecuada para contenerla. En el día a día, un SOC ejecuta cuatro bucles: monitorizar (observar las consolas y los flujos), detectar (confirmar que una señal es real), responder (contener, erradicar, recuperar) y mejorar (ajustar las detecciones para que el mismo ruido no vuelva). El último bucle es el que los SOC inmaduros se saltan, y por eso se ahogan en alertas. Un SOC sano se mide por resultados como el tiempo medio de detección y el tiempo medio de respuesta, no por cuántas alertas cerró. ## Niveles, dotación de personal y cobertura El modelo clásico divide a los analistas en niveles. El Tier 1 clasifica la cola de alertas y decide qué merece una revisión más detenida. El Tier 2 investiga los incidentes confirmados, construye la línea temporal y dirige la contención. El Tier 3 realiza una caza de amenazas proactiva y desarrolla nuevo contenido de detección en lugar de esperar a que salte una alerta. A su alrededor se sitúan ingenieros de detección, respondedores de incidentes y un responsable del SOC que es dueño del proceso y de las métricas. La cobertura es una elección deliberada con un coste real. Un SOC 8x5 vigila durante el horario laboral; un SOC 24x7 sigue el sol o organiza turnos de noche para que un atacante no pueda contar con un fin de semana tranquilo. La respuesta correcta depende de su exposición a amenazas, de sus obligaciones regulatorias y de lo que pueda sostener sin quemar al equipo. > **Un SIEM sin un SOC es solo almacenamiento** Un SIEM que nadie vigila es un archivo de registros que usted paga por llenar. El SOC es lo que convierte esa misma plataforma en un sistema de alerta temprana. Invierta en los analistas y en el proceso antes de comprar más herramientas. ## Construir, externalizar o combinar Existen tres modelos de aprovisionamiento, y la mayoría de las organizaciones acaban en algún punto intermedio. **Comparativa de modelos de aprovisionamiento del SOC** | Modelo | Quién lo opera | Mejor encaje | | --- | --- | --- | | Interno | Sus propios analistas y herramientas | Entornos de alta sensibilidad que desean un control y un contexto completos | | Externalizado (MSSP) | Un Managed Security Service Provider | Equipos que necesitan cobertura 24x7 con rapidez sin contratar una plantilla completa | | Híbrido | Responsables internos más un MSSP o un MDR para fuera del horario laboral | La mayoría de las organizaciones de tamaño medio que equilibran coste, cobertura y control | Externalizar la vigilancia no externaliza la responsabilidad. Un MSSP puede cubrir el turno de noche, pero su equipo sigue siendo dueño del inventario de activos, de las decisiones de respuesta que afectan a su negocio y de la relación con el resto de TI. El modo de fallo habitual consiste en tratar a un MSSP como algo que se contrata y se olvida, para luego descubrir durante un incidente que nadie cartografió sus sistemas más críticos ni acordó quién puede aislar un host. ## Dónde se sitúa el SOC en la gobernanza El SOC es una capacidad operativa, pero no vive en el vacío. Ejecuta la parte de detección y respuesta de marcos como el conjunto de funciones del NIST Cybersecurity Framework (identificar, proteger, detectar, responder, recuperar) y aporta evidencias que respaldan los controles ISO/IEC 27001 de registro, monitorización y gestión de incidentes. Bajo regulaciones como NIS2 y DORA, la capacidad de detectar y notificar incidentes con rapidez ya no es opcional, y el SOC suele ser el lugar donde esa capacidad se operativiza. Para los profesionales, esto significa que un SOC se juzga no solo por su tasa técnica de detección, sino por si es capaz de producir la línea temporal, las evidencias y las notificaciones que esperan auditores y reguladores. --- ## Security Orchestration, Automation and Response (SOAR) **URL:** https://cyberacademy.net/es/resources/encyclopedia/soar **Last reviewed:** 2026-06-24 SOAR es la capa que toma las alertas del SIEM y ejecuta playbooks: enriquecimiento, triaje, contención y ticketing. Objetivo: reducir el MTTR y liberar a los analistas de tareas de copiar y pegar. Precaución con las promesas excesivas de los fabricantes: un SOAR vale lo que valen los playbooks que se escriben y mantienen. La mayoría de los proyectos SOAR fallidos se quedaron sin autores de playbooks. ## Lo que el SOAR añade por encima del SIEM Security Orchestration, Automation and Response es la capa de acción que se sitúa detrás de la detección. Un SIEM es bueno recopilando registros, correlacionándolos y generando alertas, pero se detiene en la alerta. El SOAR toma el relevo desde ahí y hace el trabajo que de otro modo un analista realizaría a mano: enriquece la alerta con búsquedas de reputación y contexto de activos, decide su grado de urgencia, abre o actualiza un ticket y, cuando la política lo permite, toma medidas de contención como aislar un host, deshabilitar una cuenta o bloquear un indicador en el firewall. La unidad de trabajo en un SOAR es el playbook, una secuencia de pasos codificada que convierte un procedimiento repetible de gestión de incidentes en algo que la plataforma puede ejecutar por sí sola. La orquestación y la automatización son dos ideas distintas que el acrónimo agrupa. La orquestación es el cableado: conectar el SIEM, el EDR, el sistema de ticketing, el proveedor de identidad, las fuentes de inteligencia de amenazas y el firewall para que puedan intercambiar datos y comandos entre sí a través de una sola consola. La automatización es lo que se ejecuta a través de ese cableado sin intervención humana. La mayoría de los equipos maduros mantienen un punto de aprobación humana en los pasos destructivos, de modo que la plataforma enriquece y clasifica automáticamente, pero espera a que un analista confirme antes de poner en cuarentena un servidor de producción. Esa mezcla, el trabajo tedioso automatizado con el criterio humano en las acciones de consecuencias importantes, es lo que los profesionales realmente despliegan. ## SIEM, SOAR y el SOC Estos tres términos van juntos y es fácil confundirlos. No son productos que compitan entre sí. Describen funciones diferentes dentro de una misma operación de detección y respuesta. **SIEM vs SOAR vs SOC** | Término | Qué es | Su función | | --- | --- | --- | | SIEM | Una plataforma | Recopila y correlaciona registros y telemetría, y luego genera alertas cuando algo parece anómalo. | | SOAR | Una plataforma | Toma esas alertas y ejecuta playbooks: enriquecimiento, triaje, contención, ticketing. | | SOC | Un equipo y una función | Los analistas y el proceso que operan ambos, investigan lo que las herramientas hacen aflorar y deciden qué hacer. | Léelo como una tubería. El SIEM encuentra la señal, el SOAR hace el trabajo de respuesta repetible en torno a esa señal, y el SOC son las personas que son dueñas de todo el ciclo y gestionan todo lo que los playbooks no pueden. El valor más claro del SOAR está en el volumen: informes de phishing, alertas de malware común, inicios de sesión sospechosos. Cualquier cosa que llegue de forma masiva y siga un patrón de gestión predecible es candidata a un playbook, que es de donde proviene la reducción del tiempo medio de respuesta y por qué los analistas dejan de pasar su turno haciendo enriquecimiento de copiar y pegar. ## Por qué los proyectos SOAR triunfan o fracasan La shortDefinition es contundente sobre la trampa, y coincide con lo que se ve en el campo: un SOAR solo vale lo que valen los playbooks que escribes y mantienes, y la mayoría de los proyectos SOAR fracasados se quedaron sin autores de playbooks. La plataforma viene con conectores y un motor de flujos de trabajo, pero viene sin ningún conocimiento de tu entorno. Cada playbook tiene que diseñarse, construirse, probarse contra alertas reales y luego mantenerse a medida que cambian tus herramientas, tu red y tus atacantes. Un playbook que llama a una API que quedó obsoleta el trimestre pasado es peor que ningún playbook, porque falla en silencio en mitad de un incidente. Desde el ángulo de la gobernanza, el SOAR es la forma en que varios objetivos de control dejan de ser aspiracionales. Dentro de un sistema de gestión de la seguridad de la información ISO/IEC 27001, respalda la parte técnica de la gestión de incidentes, el registro y la supervisión, y produce un registro coherente y con marca de tiempo de cómo se gestionó cada incidente, que es exactamente la evidencia que quiere un auditor. También sustenta la capacidad de respuesta que el NIST Cybersecurity Framework presupone y que regulaciones como NIS2 y DORA esperan que las organizaciones mantengan, en particular en torno a la gestión y notificación oportunas de incidentes significativos. Trata el SOAR como un multiplicador de fuerza para un proceso que funciona, no como un sustituto de tener uno. > **Automatiza el procedimiento en el que ya confías** Un playbook codifica un procedimiento de respuesta. Si el procedimiento manual es confuso o no está acordado, automatizarlo solo hace que lo incorrecto suceda más rápido. Escribe y valida primero el runbook con tus analistas, luego codifícalo y mantén un punto de aprobación humana en cualquier paso que pueda dejar fuera de línea un sistema o una cuenta. --- ## Seudonimización **URL:** https://cyberacademy.net/es/resources/encyclopedia/pseudonymisation **Last reviewed:** 2026-06-24 La seudonimización es la técnica definida en el artículo 4(5) del GDPR que consiste en sustituir los identificadores directos por tokens reversibles, con la clave almacenada por separado. Reduce el riesgo y genera buena disposición regulatoria, pero los datos siguen siendo datos personales. La anonimización es la variante que escapa completamente al GDPR; la seudonimización, no. Atención a la confusión entre ambos conceptos. ## Lo que realmente hace la seudonimización La seudonimización es una técnica de protección de datos, no un estado que el dato alcance. Tomas los campos que apuntan directamente a una persona, el nombre, el correo electrónico, el número nacional de identidad, y los sustituyes por un token: un identificador aleatorio, una referencia codificada, un valor cifrado. La correspondencia que convierte de nuevo el token en la identidad real, la clave, se conserva por separado y se protege con sus propias medidas técnicas y organizativas. Cualquiera que trabaje con el conjunto de datos seudonimizado puede analizarlo, compartirlo o realizar pruebas sobre él sin ver a quién pertenecen los registros, mientras la organización conserva la capacidad de reidentificar cuando tiene un motivo legítimo para hacerlo. El GDPR nombra explícitamente esta técnica y la trata como una salvaguarda recomendada. Aparece como una forma de cumplir la protección de datos desde el diseño y por defecto, como una medida que puede reducir el riesgo residual de una actividad de tratamiento, y como un factor que las autoridades de control ponderan favorablemente al evaluar si has hecho lo suficiente. Usarla es una señal de que te tomaste en serio la seguridad y la minimización. Esa es la buena disposición a la que apunta la definición breve, y es real, pero no cambia la naturaleza jurídica del dato. ## La seudonimización no es anonimización Esta es la confusión que mete a las organizaciones en problemas. Como un registro seudonimizado ya no lleva un nombre visible, se supone que ha quedado fuera del ámbito del reglamento. No lo ha hecho. La seudonimización es reversible por diseño: la clave existe, de modo que el dato puede vincularse de nuevo a una persona identificable, por lo que sigue siendo un dato personal y todas las obligaciones continúan aplicándose. La anonimización es el trato opuesto. Es irreversible, el vínculo con la persona se destruye de forma tan completa que la reidentificación ya no es razonablemente posible por ningún medio que probablemente se utilice, y solo entonces el dato queda completamente fuera del GDPR. **Seudonimización frente a anonimización** | Aspecto | Seudonimización | Anonimización | | --- | --- | --- | | Reversible | Sí, mediante la clave conservada por separado | No, el vínculo se destruye | | Sigue siendo dato personal | Sí | No | | Se aplica el GDPR | Sí, en su totalidad | No | | Finalidad típica | Reducir el riesgo conservando la utilidad y la reidentificación | Sacar el dato del ámbito, a menudo para su publicación abierta | > **La clave es lo que lo convierte en dato personal** Mientras la clave o el método de reidentificación exista en cualquier lugar al alcance razonable, el dato está seudonimizado, no anonimizado. Borrar la clave, no enmascarar el nombre, es lo que cruza la línea hacia la anonimización. Trata con recelo cualquier afirmación de anonimización hasta que puedas demostrar que no existe ningún camino razonable de vuelta a la persona. ## Lo que realmente hacen los profesionales En la práctica, la seudonimización es una disciplina de ingeniería y de gobernanza más que un único interruptor. El propósito de separar la clave queda anulado si el mismo equipo, sistema o copia de seguridad guarda a la vez los tokens y la correspondencia, de modo que los controles en torno a la clave importan tanto como la tokenización en sí. - Sustituir los identificadores directos por tokens, usando métodos como el hash con clave, el cifrado o una tabla de búsqueda de referencias aleatorias. - Almacenar la clave de reidentificación por separado, bajo un control de acceso más estricto que el conjunto de datos de trabajo, idealmente en manos de un equipo diferente. - Protegerse frente a la reidentificación indirecta, donde combinaciones poco frecuentes de los campos restantes (un código postal, más una fecha de nacimiento, más un cargo) permiten singularizar a alguien incluso sin nombre. - Documentar la técnica en el registro de actividades de tratamiento y en la EIPD, y tratar el dato seudonimizado como dato personal a efectos de evaluación de brechas, conservación y derechos de los interesados. Bien hecha, la seudonimización permite que la analítica, la investigación y las pruebas de software se ejecuten sobre datos realistas a la vez que reduce el radio de impacto de una brecha, porque un atacante que obtiene los tokens sin la clave dispone de mucho menos. Hecha con descuido, con la clave accesible o los identificadores indirectos ignorados, ofrece la apariencia de protección sin la sustancia, y la organización sigue cargando con cada obligación que creía haber esquivado. --- ## Sistema de Gestión de Seguridad de la Información (ISMS) **URL:** https://cyberacademy.net/es/resources/encyclopedia/isms **Last reviewed:** 2026-06-24 Un ISMS es el sistema documentado que se opera para proteger los activos de información: basado en riesgos, respaldado por evidencias y sometido a revisión por la dirección. No es un archivador de políticas. Los auditores no evalúan las políticas; evalúan las evidencias operativas. Ciclo Plan-Do-Check-Act, certificado bajo ISO 27001, con el SoA como artefacto central. ## Qué es realmente un SGSI Un sistema de gestión de seguridad de la información es el sistema operativo que pone en marcha para proteger los activos de información de forma deliberada y repetible. La palabra que más importa es «sistema». No son las herramientas de seguridad, ni una carpeta de políticas aprobadas guardada en una unidad compartida. Es el conjunto de procesos, roles, decisiones y registros mediante el cual una organización identifica qué información debe proteger, decide cuánto riesgo está dispuesta a aceptar, elige controles para tratar ese riesgo y luego demuestra que esos controles funcionan realmente con el tiempo. Una política dice lo que debería ocurrir. Un SGSI es la maquinaria que hace que ocurra y que genera la evidencia de que así fue. Sus características definitorias son que se basa en el riesgo y se sustenta en evidencia, y que opera bajo revisión por la dirección. Basarse en el riesgo significa que los controles no se eligen de una lista de deseos, sino que se justifican mediante una evaluación documentada de las amenazas a activos concretos. Sustentarse en evidencia significa que cada control tiene artefactos que lo respaldan: revisiones de acceso que se realizaron, registros que se monitorizaron, incidentes que se gestionaron, formación que se impartió. La revisión por la dirección significa que el liderazgo es propietario del sistema, fija sus objetivos e inspecciona periódicamente si se están cumpliendo. Quite cualquiera de esos tres elementos y tendrá un programa de seguridad, no un sistema de gestión. ## Por qué los auditores califican la evidencia, no las políticas Un malentendido común y costoso es creer que la certificación consiste en tener buena documentación. No es así. Un auditor de certificación da por sentado que usted sabe redactar una política de control de acceso competente. Lo que va a verificar es si su realidad operativa coincide con lo que afirman sus documentos. Pedirá ver la última revisión de acceso y comprobará que efectivamente se completó, tomará una muestra de tickets para confirmar que los cambios se autorizaron, y trazará un incidente desde su detección hasta las lecciones aprendidas. Las políticas bonitas sin ninguna evidencia operativa detrás suspenden las auditorías. Por eso los profesionales describen el SGSI como algo que se pone en marcha, no algo que se redacta. > **La SoA es el artefacto central** La declaración de aplicabilidad es donde el SGSI se vuelve auditable. Enumera cada control de referencia, indica si aplica y justifica cada inclusión o exclusión frente a los resultados de la evaluación de riesgos. Un auditor lee la SoA primero porque es el mapa entre sus riesgos y sus controles, y después sale en busca de la evidencia de que cada control aplicable está operando de verdad. ## Plan-Do-Check-Act: cómo se mantiene vivo el sistema Un SGSI está concebido para mejorar de forma continua en lugar de perfeccionarse una sola vez. La mayoría de las implementaciones siguen el ciclo Plan-Do-Check-Act, que mantiene honesto al sistema: 1. Plan: establecer el alcance, evaluar los riesgos, fijar los objetivos de seguridad y seleccionar los controles para tratar los riesgos que ha identificado. 1. Do: implementar y operar esos controles y los procesos de apoyo en el día a día. 1. Check: monitorizar, medir, auditar internamente y realizar revisiones por la dirección para ver si los controles funcionan y si se están cumpliendo los objetivos. 1. Act: corregir lo que falla, abordar las causas raíz de las no conformidades y retroalimentar las mejoras en el siguiente ciclo. Ese bucle es lo que separa un SGSI vivo de un esfuerzo de cumplimiento puntual. Un registro de riesgos revisado una vez al año y nunca vuelto a tocar no es un SGSI en ningún sentido útil, aunque en algún momento produjera un certificado. ## Dónde se sitúa entre conceptos vecinos El SGSI es el marco, certificado conforme a la ISO/IEC 27001, la norma internacional que especifica los requisitos que debe cumplir un sistema de gestión. La ISO/IEC 27001 es la norma de requisitos certificable; guías complementarias como la ISO/IEC 27005 apoyan el trabajo de evaluación y tratamiento de riesgos que la alimenta. A menudo se confunde el SGSI con los controles que contiene, pero los controles son entradas que el sistema selecciona y opera. No son el sistema. La disciplina del SGSI consiste precisamente en que obliga a remitir cada control a un riesgo y cada riesgo a una decisión documentada tomada por personas que son responsables de ella. --- ## Tiempo Medio de Detección / Recuperación (MTTD / MTTR) **URL:** https://cyberacademy.net/es/resources/encyclopedia/mttd-mttr **Last reviewed:** 2026-06-24 MTTD es el tiempo promedio desde el inicio de un incidente hasta su detección. MTTR es el tiempo promedio desde la detección hasta la recuperación. Juntos constituyen las métricas operativas clave de un SOC y de un programa de respuesta a incidentes. Los benchmarks del sector se sitúan en días o semanas; los programas maduros apuntan a horas. ## Dos métricas, una sola línea temporal El MTTD y el MTTR describen dos segmentos consecutivos de la misma línea temporal de un incidente. El MTTD cubre el periodo silencioso entre el momento en que un atacante actúa por primera vez y el momento en que su equipo se da cuenta de que algo va mal. El MTTR cubre todo lo posterior a ese punto, desde el triaje hasta la contención y la recuperación, hasta un retorno confirmado a la normalidad. Leerlos juntos es precisamente la cuestión: un MTTD bajo con un MTTR alto significa que detecta las amenazas con rapidez pero le cuesta actuar sobre ellas, mientras que un MTTD alto con un MTTR bajo significa que responde rápido, pero solo una vez que el daño ya está hecho. Ningún número resulta útil de forma aislada, y mejorar uno a expensas del otro rara vez ayuda. En la práctica, estos son los números destacados que un SOC reporta a la dirección, porque traducen la actividad técnica a un lenguaje que el negocio entiende: cuánto tiempo estuvimos expuestos y cuánto tardamos en cerrar la puerta. También son las métricas en torno a las cuales giran los reguladores y los marcos de referencia, incluso cuando emplean palabras distintas. Un plazo de notificación de una brecha es esencialmente un tope legal sobre una parte de su MTTR, y la obligación de detectar incidentes a su debido tiempo es la obligación de mantener bajo el MTTD. ## Qué mueve realmente estos números El MTTD viene impulsado por la visibilidad y el ajuste. No puede detectar lo que no recopila, de modo que la cobertura de registros en los endpoints, la red, la identidad y la nube constituye la base. Por encima de eso, el contenido de detección debe ajustarse: demasiado laxo y los analistas se ahogan en falsos positivos y pierden la señal real, demasiado estricto y las intrusiones genuinas se cuelan. Por eso un SIEM, una buena ingeniería de detección y la inteligencia sobre amenazas alimentan directamente el MTTD. El MTTR viene impulsado por el proceso y la autoridad: manuales documentados, la potestad de aislar un host o deshabilitar una cuenta sin esperar a un comité, copias de seguridad probadas y comunicación ensayada. La mejora clásica aquí es la automatización mediante un SOAR, que elimina los minutos perdidos en los traspasos manuales. **El MTTD frente al MTTR de un vistazo** | Aspecto | MTTD (Detectar) | MTTR (Recuperar) | | --- | --- | --- | | Ventana del reloj | Del inicio del incidente a la detección | De la detección a la recuperación total | | Pregunta principal | ¿Cuánto tiempo estuvimos a ciegas? | ¿Cuánto tiempo para contener y restaurar? | | Palancas principales | Cobertura de registros, ajuste de la detección, inteligencia sobre amenazas | Manuales, automatización, autoridad para actuar, copias de seguridad | | Herramientas | SIEM, EDR, detección de amenazas | SOAR, runbooks de respuesta a incidentes, herramientas de recuperación | | Foco del responsable | Ingeniería de detección y monitorización | Respuesta a incidentes y operaciones | > **Defina el reloj antes de confiar en el número** El MTTD y el MTTR solo son comparables si todos están de acuerdo en los puntos de inicio y de parada. ¿El MTTR termina en la contención, en la erradicación o en un retorno al servicio verificado? ¿El MTTD comienza en la primera acción maliciosa o en el primer evento de registro que casualmente capturó? Hasta que esas definiciones no estén escritas, un número que baja puede significar simplemente que cambió la forma de medir. ## Cómo aparecen las métricas en las normas y los puntos de referencia Los marcos de referencia no suelen imponer un objetivo concreto de MTTD o de MTTR, porque el número correcto depende de la organización y de la amenaza. Lo que exigen es la capacidad y la medición. La ISO/IEC 27035 establece el ciclo de vida de la gestión de incidentes que estas métricas cuantifican. Las directrices del NIST para el tratamiento de incidentes plantean la detección, el análisis, la contención, la erradicación y la recuperación como fases distintas, que es exactamente la estructura sobre la que se asientan el MTTD y el MTTR. ENISA y agencias nacionales como ANSSI transmiten el mismo mensaje operativo: detectar pronto, responder rápido y poder demostrarlo. Los regímenes regulatorios añaden plazos externos estrictos, por ejemplo las ventanas de notificación de brechas previstas en el RGPD y las obligaciones de notificación de incidentes previstas en NIS2 y DORA, que convierten una parte de su tiempo de respuesta en un requisito de cumplimiento más que en un objetivo de rendimiento. Los puntos de referencia para ambas métricas tienden a situarse incómodamente altos en todo el sector, a menudo del orden de días o semanas para la detección, mientras que los programas maduros apuntan a horas. Perseguir un punto de referencia publicado es, sin embargo, el instinto equivocado. El valor del MTTD y del MTTR reside en las líneas de tendencia que usted posee: mídalas de forma coherente, observe la dirección a lo largo de los trimestres y vincule el movimiento a inversiones concretas en visibilidad, ajuste y automatización. Un número definido con honestidad y que baja de forma constante vale mucho más que una cifra halagadora y puntual. --- ## Tratamiento del riesgo **URL:** https://cyberacademy.net/es/resources/encyclopedia/risk-treatment **Last reviewed:** 2026-06-24 El tratamiento del riesgo es lo que se hace una vez que se conoce el riesgo: evitar, reducir, transferir, aceptar. Cada decisión queda documentada, justificada por el apetito al riesgo y trazada a través del SoA hasta los controles y la evidencia operativa. La mayoría de las auditorías fallidas se reducen a una sola cosa: el plan de tratamiento y la realidad divergieron, y nadie actualizó el SoA. ## Las cuatro opciones de tratamiento El tratamiento del riesgo es la fase en la que la evaluación se convierte en acción. Una vez que un riesgo ha sido identificado, analizado y evaluado frente a tus criterios, debes decidir qué hacer con él. El vocabulario convencional, compartido por ISO 31000 e ISO/IEC 27005, te ofrece cuatro familias de respuesta. No están ordenadas de la mejor a la peor; la elección correcta depende del riesgo, del coste del control y del apetito que la dirección haya aprobado. - Evitar: detener la actividad que genera el riesgo, o realizarla de otra manera. Das de baja el servicio expuesto, eliminas la funcionalidad o sales del mercado que provoca la exposición. - Reducir (modificar): aplicar controles que disminuyan la probabilidad, el impacto, o ambos. Es la vía más habitual y la que se vincula directamente con tu conjunto de controles. - Transferir (compartir): trasladar parte de la consecuencia financiera u operativa a un tercero, normalmente mediante un seguro o una cláusula contractual. La transferencia rara vez traslada el riesgo completo; te queda el residuo reputacional y regulatorio. - Aceptar (retener): decidir que el riesgo residual es tolerable y convivir con él, dejando constancia. La aceptación es una decisión legítima, no una falta de acción, siempre que la firme la autoridad adecuada. > **La aceptación es una decisión, no un estado por defecto** Un riesgo que nunca trataste no es lo mismo que un riesgo que aceptaste formalmente. La aceptación tiene que ser explícita, fechada y firmada por alguien con la autoridad que tu apetito de riesgo le asigna. Un riesgo sin tratar que reposa silenciosamente en el registro es exactamente lo que un auditor señala. ## De la decisión a la evidencia: la cadena que siguen los auditores Lo difícil del tratamiento del riesgo no es elegir una opción, es mantener coherente el rastro documental. Cada decisión debe justificarse por referencia al apetito de riesgo documentado, recogerse en un plan de tratamiento del riesgo y, a continuación, trazarse hasta los controles que la implementan y la evidencia de que operan. En un sistema de gestión de la seguridad de la información ISO/IEC 27001 es donde reside la Declaración de Aplicabilidad (SoA): registra qué controles del Anexo A se aplican, por qué y dónde se encuentra la evidencia. El hallazgo de auditoría más frecuente en este ámbito es la deriva. El plan de tratamiento decía una cosa, la SoA decía otra, y la operación sobre el terreno había avanzado más allá de ambas. Se retira un control, un proyecto cambia de alcance, se sustituye a un proveedor, y nadie actualiza los documentos. Las decisiones pueden haber sido todas razonables por separado, pero la cadena ya no concilia, y esa incoherencia es la que produce una no conformidad. ### Riesgo residual y reevaluación El tratamiento no hace desaparecer un riesgo. Lo que queda tras aplicar los controles es el riesgo residual, y esa es la cifra que el propietario del riesgo acepta realmente. La buena práctica consiste en volver a ejecutar el análisis sobre el riesgo tratado para que el nivel residual quede explícito, y luego encaminarlo de nuevo a la misma autoridad de aceptación. ISO/IEC 27005, alineada desde su revisión de 2022 con los principios de ISO 31000, lo plantea como un bucle iterativo y no como un ejercicio puntual: tratas, mides lo que queda, aceptas o vuelves a tratar. ## Lo que los profesionales hacen realmente En el trabajo diario de GRC, el tratamiento del riesgo se gestiona como un plan vivo y no como un entregable de proyecto. Un ritmo viable se parece a esto: 1. Vincula cada decisión de tratamiento a un riesgo nombrado en el registro y al enunciado de apetito que la justifica, para que la motivación sobreviva a la rotación de personal. 1. Asigna un único responsable rendidor de cuentas y una fecha objetivo a cada acción de «reducir», y haz su seguimiento como cualquier otro compromiso. 1. Mantén conciliados la SoA, el plan de tratamiento y la evidencia de los controles con una cadencia fija, no solo antes de una auditoría. 1. Registra el riesgo residual y la firma de aceptación para todo aquello que no mitigues por completo, incluidos los riesgos que transfieres. Hecho así, el plan de tratamiento deja de ser teatro de auditoría y se convierte en el lugar donde la organización puede decir con honestidad a qué está expuesta y quién decidió que eso era aceptable. --- ## Zero Trust **URL:** https://cyberacademy.net/es/resources/encyclopedia/zero-trust **Last reviewed:** 2026-06-24 Zero Trust es el modelo de seguridad en el que se deja de confiar en el perímetro de red. Cada decisión de acceso se autentica, autoriza y evalúa en contexto, en cada ocasión. La identidad se convierte en el perímetro. Nació en Forrester, lo popularizó BeyondCorp de Google y lo codificó NIST SP 800-207. Vaya más allá de los argumentarios de los fabricantes: es una arquitectura, no un producto. ## De la confianza perimetral a la verificación de cada solicitud El modelo tradicional trataba la red corporativa como una zona de confianza. Una vez dentro del cortafuegos, a través de la VPN, detrás del perímetro, se te concedía implícitamente confianza para moverte lateralmente. El Zero Trust rechaza esa premisa. No existe un interior de confianza. Una solicitud desde un portátil conectado a la red local de la oficina se trata con la misma sospecha que una solicitud desde una cafetería, porque la ubicación ya no se gana la confianza. Cada decisión de acceso se toma de nuevo: quién pregunta, desde qué dispositivo, con qué postura, para qué recurso, en qué contexto, y si esa combinación está autorizada en este preciso momento. Esto importa porque el perímetro se disolvió en la práctica hace años. El personal trabaja desde casa, las aplicaciones residen en el SaaS de un tercero, y una sola credencial robada mediante phishing solía significar libertad de movimiento por todo el parque. El Zero Trust reduce ese radio de impacto. El atacante que roba una contraseña todavía se enfrenta a comprobaciones de dispositivo, autorización continua y segmentación en cada salto, de modo que una sola vulneración ya no se convierte en una brecha completa. ## Lo que los profesionales construyen realmente Mira más allá de las presentaciones comerciales de los proveedores. El Zero Trust es una arquitectura y un modelo operativo, no una caja que se compra. NIST SP 800-207 lo describe en términos de un motor de políticas que toma las decisiones, un administrador de políticas que las aplica, y puntos de aplicación de políticas situados delante de los recursos. El trabajo práctico consiste en hacer de la identidad el plano de control y verificar cada solicitud frente a la política. Los bloques de construcción recurrentes son: - Identidad y autenticación sólidas, con MFA como base en lugar de como añadido, para que la identidad que origina una solicitud quede verificada de verdad. - Postura y estado de salud del dispositivo, porque un usuario verificado en un dispositivo comprometido o no gestionado sigue siendo un riesgo que merece evaluarse. - Mínimo privilegio y acceso justo a tiempo, concediendo los derechos más reducidos necesarios y eliminando el acceso permanente que los atacantes adoran heredar. - Microsegmentación, para que un punto de apoyo en una carga de trabajo no abra un camino plano hacia todo lo demás. - Evaluación y registro continuos, porque la confianza se reevalúa a medida que cambia el contexto, y no se concede una sola vez al iniciar sesión y se olvida. > **Es un trayecto, no un interruptor** Ninguna organización cambia un único ajuste y se convierte en Zero Trust. La madurez es incremental: empieza por la identidad y el MFA, ajusta los privilegios, segmenta la red y, después, añade una capa de supervisión continua. Recibe con un escepticismo sano cualquier producto vendido como Zero Trust llave en mano: en el mejor de los casos es un punto de aplicación dentro de una arquitectura mucho más amplia. ## En qué se diferencia de ideas vecinas El Zero Trust es fácil de confundir con los principios sobre los que se construye. El mínimo privilegio es uno de sus ingredientes: limita lo que una identidad puede alcanzar, pero por sí solo todavía da por sentado que la red es de confianza. La defensa en profundidad es el instinto más antiguo y amplio de superponer controles independientes; el Zero Trust es una forma específica de eliminar ese interior blando y de confianza que las defensas en capas clásicas solían dejar en su sitio. La gestión de identidades y accesos aporta la maquinaria, los directorios, la autenticación y la autorización, que el Zero Trust utiliza como base. En pocas palabras, el IAM, el MFA y el mínimo privilegio son componentes, mientras que el Zero Trust es la filosofía de diseño que los orquesta en una verificación continua y contextual. En el panorama de normas y políticas, la idea es ya predominante. NIST SP 800-207 es la definición de referencia, y el NIST ha publicado guías complementarias de implementación. En Estados Unidos, los mandatos gubernamentales han impulsado a las agencias hacia arquitecturas Zero Trust, y organismos europeos como ENISA lo citan como una dirección de avance hacia una seguridad resiliente y centrada en la identidad. Los auditores esperan cada vez más ver los principios reflejados en el diseño de accesos, incluso cuando un marco no nombra el Zero Trust de forma explícita. --- # COURSES CATALOGUE ## CISA: Certified Information Systems Auditor **URL:** https://cyberacademy.net/es/courses/cisa **Issuer:** ISACA **Level:** practitioner **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La credencial de referencia de ISACA para auditoría de TI. Cinco dominios, examen de cuatro horas, la certificación de auditoría por defecto en los encargos de las Big Four. Cohorte de cuatro días con una convocatoria de recuperación incluida. **You will learn how to:** - Planificar y ejecutar una auditoría de SI basada en riesgos, alineada con los estándares de ISACA. - Evaluar el gobierno y la gestión de TI frente a COBIT e ISO 27001. - Valorar los controles en la adquisición, el desarrollo y la implantación de SI. - Auditar las operaciones de SI, la resiliencia del negocio y la protección de activos. - Elaborar informes de auditoría que superen una revisión de las Big Four. **For:** - Auditores de TI que pasan de la auditoría interna a un rol especializado en auditoría de SI. - Responsables de cumplimiento en sectores regulados (banca, seguros, sanidad). - Analistas de seguridad en transición hacia auditoría o GRC. - Consultores de las Big Four orientados a encargos de cara al cliente. **NOT for (when you should not take this certification):** - Futuros CISO sin interés en auditoría. CISM es la alternativa orientada a la gestión. - Gestores de riesgos sin enfoque auditor. CRISC se adapta mejor. - Profesionales con menos de tres años de experiencia. ISACA solo reconoce la experiencia obtenida en los diez años anteriores a la solicitud. --- ## CISM: Certified Information Security Manager **URL:** https://cyberacademy.net/es/courses/cism **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La certificación de referencia de ISACA para la gestión de la seguridad. Cuatro dominios; presente en aproximadamente el 60% de las ofertas de empleo para CISO. Cohorte de cuatro días con una repetición del examen incluida. **You will learn how to:** - Diseñar y gobernar un programa de seguridad de la información alineado con la estrategia de negocio. - Ejecutar un proceso de gestión del riesgo de la información que alimente las decisiones a nivel de consejo. - Construir y operar el programa de seguridad (recursos, arquitectura, concienciación, riesgo de proveedores). - Liderar la gestión de incidentes, desde la preparación hasta las lecciones aprendidas. - Traducir la postura técnica de seguridad en un relato para el consejo sin perder precisión. **For:** - CISO en perspectiva y CISO adjuntos. - Arquitectos de seguridad que pasan a roles de gestión de personas. - Directores de TI que asumen la cartera de seguridad. - Consultores que asesoran en el diseño de programas de seguridad. **NOT for (when you should not take this certification):** - Ingenieros de seguridad operativa sin ambición de gestión. CISSP u otras certificaciones técnicas especializadas encajan mejor. - Auditores de SI sin interés operativo. CISA sigue siendo la certificación principal. - Analistas de seguridad junior con menos de tres años de experiencia. --- ## CRISC: Certified in Risk and Information Systems Control **URL:** https://cyberacademy.net/es/courses/crisc **Issuer:** ISACA **Level:** risk-manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La credencial de referencia de ISACA para el riesgo TI. Cuatro dominios que conectan el riesgo de negocio con los controles de SI. El complemento natural de CISA y de ISO 31000 / 27005 para el vocabulario ISACA. **You will learn how to:** - Integrar la gestión del riesgo TI en el gobierno corporativo. - Identificar, evaluar y priorizar el riesgo TI frente a los objetivos de negocio. - Diseñar opciones de respuesta al riesgo alineadas con el apetito y la tolerancia al riesgo. - Monitorizar el riesgo TI e informar al consejo en un lenguaje que impulse la acción. - Mapear el vocabulario CRISC sobre ISO 31000 / 27005 / NIST RMF en auditorías mixtas. **For:** - Gestores de riesgo TI, analistas GRC y consultores de riesgo. - Analistas de negocio que se incorporan al riesgo TI. - Auditores de SI que amplían su perfil desde las pruebas de controles hacia la consultoría de riesgo. - CISOs y CISOs adjuntos que necesitan el vocabulario de cuantificación del riesgo que el consejo reconoce. **NOT for (when you should not take this certification):** - Profesionales de riesgo puramente técnico (gestión de vulnerabilidades, threat hunting). Considerar CISSP u otras credenciales especializadas. - Profesionales de riesgo formados en ISO que no trabajan en un contexto TI o SI. ISO 31000 Lead Risk Manager tiene un alcance más amplio. - Profesionales con menos de tres años de experiencia laboral relevante. --- ## AAIA: Advanced in AI Audit **URL:** https://cyberacademy.net/es/courses/aaia **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credencial avanzada de ISACA para auditores que se incorporan al ámbito de la IA. Metodología de auditoría para sistemas de IA, evaluación de riesgos de IA y marcos de gobernanza de IA. Intensivo de tres días; se recomienda CISA como base. **You will learn how to:** - Planificar y ejecutar una auditoría de sistemas de IA frente a los requisitos del ISO 42001 AIMS y las obligaciones del AI Act. - Evaluar los controles del ciclo de vida del modelo (gobernanza de datos, entrenamiento, validación, monitorización y retirada). - Comprobar los controles de equidad, explicabilidad y supervisión de sesgos de la IA frente a las expectativas regulatorias y de auditoría. - Auditar el riesgo de proveedores de IA y las dependencias de modelos de terceros. - Elaborar informes de auditoría de IA que soporten la revisión de organismos notificados y autoridades supervisoras. **For:** - Auditores TI senior que se incorporan al aseguramiento de IA. - Responsables de GRC que desarrollan un programa de auditoría de IA. - Responsables de cumplimiento en sectores regulados que despliegan IA (banca, seguros, sanidad, sector público). - Senior managers y directores de las Big Four que asumen el liderazgo de proyectos de IA. **NOT for (when you should not take this certification):** - Profesionales sin experiencia en auditoría. Primero CISA, después AAIA. - Ingenieros de IA que desean aprender auditoría. El AAIA presupone fluidez en auditoría; ISO 42001 Lead Auditor es un punto de partida más adecuado. - Auditores junior con menos de dos años de experiencia. --- ## AAIR: Advanced in AI Risk **URL:** https://cyberacademy.net/es/courses/aair **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credencial avanzada de ISACA para gestores de riesgo que desarrollan un programa de riesgo en IA. Evaluación del riesgo de IA, tratamiento del riesgo, gobernanza del riesgo de IA. Intensivo de tres días; se recomienda CRISC como base. **You will learn how to:** - Integrar el riesgo de IA en el marco de gestión de riesgos empresarial junto al riesgo cibernético, operacional y estratégico. - Evaluar el riesgo de IA a lo largo del ciclo de vida del modelo (incorporación, diseño, despliegue, monitorización, retirada) mediante metodología alineada con AIMS. - Cuantificar los riesgos específicos de IA (sesgo, alucinación, deriva del modelo, exposición regulatoria bajo el AI Act) para la presentación al consejo. - Diseñar opciones de tratamiento del riesgo de IA equilibrando la velocidad de innovación frente a la exposición regulatoria y reputacional. - Construir telemetría de monitorización y reporte del riesgo de IA para la supervisión continua. **For:** - Gestores de riesgo TI que amplían su cartera hacia la IA. - CROs y subdirectores de riesgo que incorporan la IA a la taxonomía de riesgos empresarial. - Responsables de GRC que desarrollan el flujo de trabajo de riesgo de IA. - Responsables de cumplimiento en sectores regulados que cuantifican la exposición a la IA para su aprobación por el consejo. **NOT for (when you should not take this certification):** - Profesionales sin formación en gestión de riesgos. Primero CRISC o ISO 31000 Lead Risk Manager. - Ingenieros de IA que desean aprender sobre riesgo. AAIR presupone competencia como profesional del riesgo. - Analistas de riesgo junior con menos de dos años de experiencia. --- ## AAISM: Advanced in AI Security Management **URL:** https://cyberacademy.net/es/courses/aaism **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 La credencial avanzada de ISACA para gestores de seguridad que construyen un programa de seguridad en IA. Modelado de amenazas en IA, ciclo de vida seguro del modelo, operaciones de seguridad en IA. Intensivo de tres días; se recomienda CISM como base. **You will learn how to:** - Diseñar y gobernar un programa de seguridad en IA alineado con ISO 42001 y el AI Act. - Ejecutar el modelado de amenazas en IA (inyección de prompts, envenenamiento de modelos, ejemplos adversariales, exfiltración de datos por inferencia). - Operar la seguridad en IA en producción: monitorización, respuesta a incidentes, deriva del modelo y riesgo en la cadena de suministro para dependencias de modelos fundacionales. - Integrar la seguridad en IA en los programas más amplios de ISMS (ISO 27001) y AIMS (ISO 42001). - Traducir la postura de seguridad en IA para el consejo de administración y el comité de auditoría. **For:** - CISOs y subdirectores de seguridad que asumen la supervisión de la seguridad en IA. - Gestores de programas de seguridad que construyen el área de trabajo de seguridad en IA. - Arquitectos de seguridad que diseñan controles de seguridad para sistemas de IA. - Gestores de GRC que integran el riesgo de IA en el programa de seguridad. **NOT for (when you should not take this certification):** - Profesionales puramente ofensivos o de red team en IA. AAISM cubre gobernanza y gestión, no pentesting. - Ingenieros de ML que deseen aprender seguridad de forma práctica. CISSP o un curso técnico especializado en seguridad para IA se adaptan mejor. - Gestores de seguridad sin experiencia previa en gestión (menos de tres años). --- ## CGEIT: Certified in the Governance of Enterprise IT **URL:** https://cyberacademy.net/es/courses/cgeit **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 La credencial de referencia de ISACA para la gobernanza de TI a nivel ejecutivo. Cinco dominios que cubren el marco de gobernanza, la gestión estratégica, la realización de beneficios, la optimización del riesgo y la optimización de recursos. Diseñada para CIOs, responsables de gobernanza y directivos de TI con interlocución ante el consejo. **You will learn how to:** - Diseñar y operar un marco de gobernanza de TI empresarial alineado con COBIT y la estrategia de negocio. - Dirigir ciclos de gestión estratégica de TI que el consejo apruebe y las auditorías validen. - Cuantificar e informar sobre la realización de beneficios de las inversiones en TI. - Integrar el riesgo de TI en el marco de gestión de riesgos empresarial. - Optimizar los recursos de TI (personas, tecnología, asociaciones con proveedores) en función de los objetivos de gobernanza. **For:** - CIOs y CIOs adjuntos con responsabilidad sobre la cartera de gobernanza. - Responsables de gobernanza de TI en sectores regulados (banca, seguros, utilities, sector público). - Directores sénior de las Big Four que lideran revisiones de gobernanza. - Miembros del consejo en comités de tecnología o auditoría. **NOT for (when you should not take this certification):** - Gestores de TI operativos sin exposición ejecutiva. CISM o CRISC se ajustan mejor. - Auditores de SI que buscan una credencial de auditoría. CISA sigue siendo la credencial principal. - Profesionales con menos de cinco años de experiencia a nivel de gobernanza. --- ## CDPSE: Certified Data Privacy Solutions Engineer **URL:** https://cyberacademy.net/es/courses/cdpse **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2900 · Self-paced €790 La credencial de ISACA en la intersección entre privacidad y tecnología. Tres dominios que abarcan gobernanza de privacidad, arquitectura de privacidad y ciclo de vida de los datos. La certificación para ingenieros de privacidad que construyen sistemas conformes con GDPR, no solo políticas. **You will learn how to:** - Diseñar arquitecturas de datos que cumplan con GDPR y marcos de privacidad equivalentes desde su construcción. - Implementar controles de privacidad a lo largo del ciclo de vida del dato (recogida, tratamiento, almacenamiento, transferencia, supresión). - Realizar evaluaciones de impacto sobre la privacidad junto con revisiones de controles técnicos. - Traducir requisitos legales de privacidad en especificaciones de ingeniería que los equipos de producto puedan implementar. - Gestionar la monitorización de privacidad y la respuesta a incidentes específicos a los derechos de los interesados y a las brechas de datos. **For:** - Ingenieros de privacidad y DPOs con perfil técnico. - Arquitectos de datos y de software que construyen sistemas conformes con GDPR. - Ingenieros de seguridad que amplían su perfil hacia el privacy-by-design. - CDPOs que complementan su conocimiento jurídico con credibilidad en ingeniería. **NOT for (when you should not take this certification):** - DPOs con perfil exclusivamente jurídico y sin exposición a la ingeniería. El PECB CDPO se ajusta mejor. - Analistas de privacidad junior con menos de tres años de experiencia multidisciplinar. --- ## CCOA: Certified Cybersecurity Operations Analyst **URL:** https://cyberacademy.net/es/courses/ccoa **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2200 · Self-paced €690 La credencial práctica de ISACA para analistas de SOC y operadores de ciberdefensa. Cinco dominios que abarcan monitorización, respuesta a incidentes, threat hunting e inteligencia de amenazas. Nivel profesional; el examen combina escenarios con preguntas de opción múltiple. **You will learn how to:** - Operar una plataforma de monitorización de seguridad (SIEM, EDR, telemetría de red) a nivel SOC tier-2. - Ejecutar un ciclo completo de respuesta a incidentes desde el triaje hasta las lecciones aprendidas, con la documentación que esperan los auditores. - Llevar a cabo threat hunts basados en hipótesis utilizando MITRE ATT&CK como marco de navegación. - Consumir y producir inteligencia de amenazas accionable en formatos estándar (STIX/TAXII). - Conectar el área de operaciones de ciberseguridad con el programa GRC: incidentes convertidos en riesgo, controles integrados en telemetría. **For:** - Analistas de SOC tier-1 que buscan progresar a tier-2. - Profesionales de respuesta a incidentes que desean obtener una credencial reconocida. - Threat hunters que desean formalizar su metodología. - Ingenieros de ciberseguridad que pasan a un rol de operaciones de defensa. **NOT for (when you should not take this certification):** - Profesionales de GRC sin experiencia en operaciones. CISA o CISM se ajustan mejor. - Futuros CISOs. Considerar CISM. - Personas sin experiencia práctica en seguridad defensiva. --- ## COBIT 2019 Foundation **URL:** https://cyberacademy.net/es/courses/cobit-foundation **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1250 La certificación de nivel inicial para el marco de gobierno COBIT 2019. Cohorte de dos días que cubre la estructura del marco, los principios, los factores de diseño y los componentes del sistema de gobierno. Cohorte en directo con examen ISACA incluido. **You will learn how to:** - Navegar el marco COBIT 2019: objetivos de gobierno, objetivos de gestión y factores de diseño. - Aplicar el flujo de trabajo de diseño del sistema de gobierno a un contexto empresarial real. - Mapear COBIT con marcos adyacentes (ITIL, ISO 27001, ISO 38500, NIST CSF). - Posicionar COBIT como la capa integradora por encima de los estándares operativos en un programa multi-marco. **For:** - Responsables de TI y analistas GRC que se inician en el gobierno de TI empresarial. - Auditores que amplían su vocabulario de marcos más allá de ISO 27001. - Consultores que ofertan proyectos de diseño de sistemas de gobierno. **NOT for (when you should not take this certification):** - Ingenieros técnicos sin exposición a gobierno. - Futuros CISO que buscan una certificación de liderazgo. CISM se adapta mejor. --- ## COBIT 2019 Design & Implementation **URL:** https://cyberacademy.net/es/courses/cobit-design-implementation **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €1900 La credencial avanzada de COBIT. Cohorte de tres días centrada en aplicar los factores de diseño para construir un sistema de gobierno a medida y, a continuación, desarrollar la hoja de ruta de implementación. Cohorte en directo con examen ISACA incluido. Foundation es un prerrequisito. **You will learn how to:** - Ejecutar el flujo de trabajo de diseño de COBIT 2019 de principio a fin para una empresa real. - Puntuar y aplicar los factores de diseño para enfocar el sistema de gobierno. - Construir la hoja de ruta de implementación con la cascada de objetivos priorizados y los objetivos de capacidad. - Liderar la gestión del cambio para la adopción del gobierno en los equipos de TI y negocio. **For:** - Responsables de gobierno de TI que implementan el sistema de diseño en su organización. - Consultores GRC que presentan propuestas de diseño de gobierno. - Auditores internos que validan las decisiones de diseño del sistema de gobierno. **NOT for (when you should not take this certification):** - Profesionales sin COBIT Foundation. Curse primero Foundation. --- ## Cybersecurity Audit Certificate (ISACA) **URL:** https://cyberacademy.net/es/courses/cybersecurity-audit-certificate **Issuer:** ISACA **Level:** practitioner **Duration:** 2 days **Price:** Live €1450 El certificado ISACA dedicado a la auditoría de ciberseguridad. Cohorte de dos días, basada en escenarios, diseñada para conectar la auditoría clásica de SI (CISA) con las operaciones modernas de ciberdefensa. Útil para auditores que evalúan programas de SOC, respuesta a incidentes e inteligencia de amenazas. **You will learn how to:** - Planificar y ejecutar una auditoría de ciberseguridad que cubra monitorización, respuesta a incidentes e inteligencia de amenazas. - Evaluar controles de ciberdefensa frente a marcos del sector (NIST CSF, ISO 27001, CIS Controls). - Auditar un SOC: roles, runbooks, telemetría y métricas de incidentes. - Contrastar los ejercicios de preparación ante brechas y los resultados de tabletop con el playbook. **For:** - Auditores de SI que amplían su actividad hacia la evaluación de ciberseguridad. - Equipos de auditoría interna que incorporan el ámbito ciber a la taxonomía del universo de auditoría. - Auditores de las Big Four que revisan controles de ciberseguridad en el marco de encargos de aseguramiento más amplios. **NOT for (when you should not take this certification):** - Operadores de SOC con perfil técnico. CCOA se adapta mejor a ese perfil. --- ## Fundamentos de Auditoría TI (ISACA) **URL:** https://cyberacademy.net/es/courses/it-audit-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 El certificado ISACA de nivel inicial en auditoría TI. Cohorte de dos días que cubre planificación de auditoría, trabajo de campo, evidencia e informes con la terminología ISACA. Una incorporación sólida antes del CISA. **You will learn how to:** - Aplicar un ciclo de vida de auditoría a los controles del dominio TI. - Planificar compromisos, recopilar evidencia y redactar hallazgos que superen la revisión. - Distinguir las actividades de primera, segunda y tercera línea en una empresa típica. - Situar la auditoría TI dentro del programa de aseguramiento más amplio. **For:** - Profesionales TI que exploran una trayectoria profesional en auditoría. - Analistas GRC al inicio de su especialización en auditoría. - Consultores que se preparan para el CISA y desean una introducción estructurada. **NOT for (when you should not take this certification):** - Profesionales que ya gestionan programas de auditoría. Pasen directamente al CISA. --- ## IT Risk Fundamentals (ISACA) **URL:** https://cyberacademy.net/es/courses/it-risk-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 El certificado ISACA de nivel inicial sobre riesgo TI. Formación de dos días en cohorte que introduce la identificación, evaluación, respuesta y monitorización del riesgo con la terminología ISACA. Una base sólida antes de abordar el CRISC. **You will learn how to:** - Aplicar un ciclo de vida de gestión del riesgo a los riesgos del ámbito TI. - Construir un registro de riesgos vinculado al impacto en el negocio, no solo a los hallazgos técnicos. - Distinguir las actividades de identificación, evaluación, respuesta y monitorización del riesgo. - Situar el riesgo TI dentro del programa de riesgo empresarial más amplio. **For:** - Profesionales de TI que se inician en la gestión del riesgo. - Analistas GRC al inicio de su especialización en riesgo. - Auditores que se preparan para el CRISC y desean una base estructurada previa. **NOT for (when you should not take this certification):** - Profesionales que ya operan un programa de riesgo empresarial. Acceder directamente al CRISC. --- ## ISO27001 - Foundation **URL:** https://cyberacademy.net/es/courses/iso27001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formación oficial para la certificación ISO27001 - Foundation, acreditada por PECB. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Inscríbase... --- ## AI Risk Manager **URL:** https://cyberacademy.net/es/courses/ai-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación AI Risk Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## Certified Artificial Intelligence Professional (CAIP) **URL:** https://cyberacademy.net/es/courses/certified-artificial-intelligence-professional-caip **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación PECB Certified Artificial Intelligence Professional (CAIP). Formación online en directo con garantía de certificación o reembolso. --- ## Certified CISO by PECB **URL:** https://cyberacademy.net/es/courses/certified-ciso-by-pecb **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formación oficial acreditada por PECB para la certificación Certified CISO by PECB. Curso online en directo con instructores expertos y garantía de certificación o reembolso. Inscríbase... --- ## Certified Lead Crisis Manager **URL:** https://cyberacademy.net/es/courses/certified-lead-crisis-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Certified Lead Crisis Manager acreditada por PECB. Formación online en directo con garantía certificado o reembolso. --- ## PECB CMMC Foundations **URL:** https://cyberacademy.net/es/courses/cmmc-foundations **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formación oficial certificada por PECB para la certificación PECB CMMC Foundations. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Inscríbase... --- ## Cyber Threat Analyst **URL:** https://cyberacademy.net/es/courses/cyber-threat-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Cyber Threat Analyst acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## Cybersecurity Foundation **URL:** https://cyberacademy.net/es/courses/cybersecurity-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación Cybersecurity Foundation acreditada por PECB. Formación en vivo online con garantía de certificación o reembolso. --- ## DORA Foundation **URL:** https://cyberacademy.net/es/courses/dora-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 DORA Foundation para el sector financiero. Gestión de riesgos TIC y notificación de incidentes. Acreditado por PECB. --- ## DORA Lead Manager **URL:** https://cyberacademy.net/es/courses/dora-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Conviértase en DORA Lead Manager certificado. Implemente la resiliencia operativa digital en entidades financieras. Curso acreditado por PECB con examen incluido. --- ## EBIOS Risk Manager **URL:** https://cyberacademy.net/es/courses/ebios-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formación oficial para la certificación EBIOS RM. Aprenda la metodología de evaluación de riesgos de los 5 talleres de ANSSI. Curso acreditado por PECB con ejercicios prácticos y examen. --- ## GDPR - Certified Data Protection Officer **URL:** https://cyberacademy.net/es/courses/gdpr-certified-data-protection-officer **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación GDPR - Certified Data Protection Officer acreditada por PECB. Formación en línea en directo con garantía de certificación o reembolso. --- ## GDPR Foundation **URL:** https://cyberacademy.net/es/courses/gdpr-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación GDPR Foundation acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 22301 Foundation **URL:** https://cyberacademy.net/es/courses/iso-22301-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación ISO 22301 Foundation acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 22301 Lead Auditor **URL:** https://cyberacademy.net/es/courses/iso-22301-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 22301 Lead Auditor acreditada por PECB. Formación en directo online con garantía certificado o reembolso. --- ## ISO 22301 Lead Implementer **URL:** https://cyberacademy.net/es/courses/iso-22301-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 22301 Lead Implementer acreditada por PECB. Formación en línea en directo con garantía de certificación o reembolso. --- ## ISO 27005 Foundation **URL:** https://cyberacademy.net/es/courses/iso-27005-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formación oficial para la certificación ISO 27005 Foundation acreditada por PECB. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Inscríbase ... --- ## ISO 27005 Lead Risk Manager **URL:** https://cyberacademy.net/es/courses/iso-27005-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formación oficial certificada PECB para ISO 27005 Lead Risk Manager. Curso en directo online con instructores expertos y garantía de certificación o reembolso. ... --- ## ISO 27005 Risk Manager **URL:** https://cyberacademy.net/es/courses/iso-27005-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formación certificada por PECB en ISO 27005 Risk Manager. Domine la evaluación, el tratamiento y el seguimiento del riesgo en seguridad de la información. Metodología práctica con examen incluido... --- ## ISO 27033 Lead Network Security Manager **URL:** https://cyberacademy.net/es/courses/iso-27033-lead-network-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 27033 Lead Network Security Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 27034 Lead Application Security Auditor **URL:** https://cyberacademy.net/es/courses/iso-27034-lead-application-security-auditor **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 27034 Lead Application Security Auditor acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 27034 Lead Application Security Implementer **URL:** https://cyberacademy.net/es/courses/iso-27034-lead-application-security-implementer **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación PECB ISO 27034 Lead Application Security Implementer. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 27035 Foundation **URL:** https://cyberacademy.net/es/courses/iso-27035-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formación oficial para la certificación ISO 27035 Foundation acreditada por PECB. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Inscríbase ... --- ## ISO 27035 Lead Incident Manager **URL:** https://cyberacademy.net/es/courses/iso-27035-lead-incident-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 27035 Lead Incident Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 27701 Foundation **URL:** https://cyberacademy.net/es/courses/iso-27701-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación ISO 27701 Foundation acreditada por PECB. Formación online en directo con garantía de certificación o reembolso. --- ## ISO 27701 Lead Auditor **URL:** https://cyberacademy.net/es/courses/iso-27701-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 27701 Lead Auditor acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 27701 Lead Implementer **URL:** https://cyberacademy.net/es/courses/iso-27701-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 27701 Lead Implementer acreditada por PECB. Formación en vivo online con garantía de certificación o reembolso. --- ## ISO 31000 Foundation **URL:** https://cyberacademy.net/es/courses/iso-31000-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación ISO 31000 Foundation acreditada por PECB. Formación en vivo en línea con garantía de certificación o reembolso. --- ## ISO 31000 Lead Risk Manager **URL:** https://cyberacademy.net/es/courses/iso-31000-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 31000 Lead Risk Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 31000 Risk Manager **URL:** https://cyberacademy.net/es/courses/iso-31000-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Certificación ISO 31000 Risk Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 42001 Foundation **URL:** https://cyberacademy.net/es/courses/iso-42001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación ISO 42001 Foundation acreditada por PECB. Formación en línea en directo con garantía de certificación o reembolso. --- ## ISO 42001 Lead Auditor **URL:** https://cyberacademy.net/es/courses/iso-42001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación PECB ISO 42001 Lead Auditor. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 42001 Lead Implementer **URL:** https://cyberacademy.net/es/courses/iso-42001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 42001 Lead Implementer acreditada por PECB. Formación en línea en directo con garantía de certificación o reembolso. --- ## ISO 9001 Foundation **URL:** https://cyberacademy.net/es/courses/iso-9001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación ISO 9001 Foundation acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 9001 Lead Auditor **URL:** https://cyberacademy.net/es/courses/iso-9001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 9001 Lead Auditor acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## ISO 9001 Lead Implementer **URL:** https://cyberacademy.net/es/courses/iso-9001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación ISO 9001 Lead Implementer acreditada por PECB. Formación en línea en directo con garantía de certificación o reembolso. --- ## ISO27001 - Lead Auditor **URL:** https://cyberacademy.net/es/courses/iso27001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formación oficial para la certificación ISO27001 - Lead Auditor, acreditada por PECB. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Matrí... --- ## ISO27001 - Lead Implementer **URL:** https://cyberacademy.net/es/courses/iso27001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formación oficial para la certificación ISO27001 - Lead Implementer, acreditada por PECB. Curso en directo online con instructores expertos y garantía de certificación o reembolso. ... --- ## ISO27002 Foundation **URL:** https://cyberacademy.net/es/courses/iso27002-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Formación oficial certificada PECB para la certificación ISO27002 Foundation. Curso en línea en directo con instructores expertos y garantía de certificación o reembolso. Inscríbase y... --- ## ISO27002 Lead Manager **URL:** https://cyberacademy.net/es/courses/iso27002-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Formación oficial acreditada por PECB para la certificación ISO27002 Lead Manager. Curso en directo online con instructores expertos y garantía de certificación o reembolso. Inscríbase... --- ## ISO27002 Manager **URL:** https://cyberacademy.net/es/courses/iso27002-manager **Issuer:** PECB **Level:** manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Formación oficial certificada por PECB para la certificación ISO27002 Manager. Curso en directo en línea con instructores expertos y garantía de certificación o reembolso. Inscríbase hoy. --- ## Lead Cloud Security Manager **URL:** https://cyberacademy.net/es/courses/lead-cloud-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Lead Cloud Security Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## Lead Cybersecurity Manager **URL:** https://cyberacademy.net/es/courses/lead-cybersecurity-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Lead Cybersecurity Manager acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. --- ## Lead Disaster Recovery Manager **URL:** https://cyberacademy.net/es/courses/lead-disaster-recovery-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación PECB Lead Disaster Recovery Manager. Formación en directo online con garantía de certificación o reembolso. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/es/courses/lead-ethical-hacker **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Lead Ethical Hacker acreditada por PECB. Formación en directo online con garantía certificado o reembolso. --- ## Lead Operational Resilience Manager **URL:** https://cyberacademy.net/es/courses/lead-operational-resilience-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Lead Operational Resilience Manager acreditada por PECB. Formación en vivo online con garantía de certificación o reembolso. --- ## Lead SOC 2 Analyst **URL:** https://cyberacademy.net/es/courses/lead-soc-2-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación Lead SOC 2 Analyst acreditada por PECB. Formación online en directo con garantía de certificación o reembolso. --- ## NIS 2 Directive Foundation **URL:** https://cyberacademy.net/es/courses/nis-2-directive-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Certificación NIS 2 Directive Foundation acreditada por PECB. Formación en vivo online con garantía de certificación o reembolso. --- ## NIS 2 Directive Lead Implementer **URL:** https://cyberacademy.net/es/courses/nis-2-directive-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación PECB NIS 2 Directive Lead Implementer. Formación en línea en directo con garantía de certificación o reembolso. --- ## NIST Cybersecurity Consultant **URL:** https://cyberacademy.net/es/courses/nist-cybersecurity-consultant **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Certificación NIST Cybersecurity Consultant acreditada por PECB. Formación en directo online con garantía de certificación o reembolso. ---