> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-center-en-es/incorporacion/compliance/dora.md). # DORA Desde el 17 de enero de 2025, la **Ley de Resiliencia Operativa Digital (DORA, Reglamento (UE) 2022/2554)** exige a las entidades financieras de la UE demostrar que pueden resistir, responder y recuperarse de incidentes TIC. DORA no te pide comprar una herramienta específica. Te pide contar con medidas **y demostrarlo**. Stoïk Protect ayuda con ambas cosas: sus herramientas cubren varios requisitos técnicos y generan las pruebas (informes, historial, tasas de finalización) que esperan los auditores y supervisores. Este artículo muestra con qué requisitos de DORA ayuda cada herramienta de Stoïk Protect y qué sigue siendo tu responsabilidad. {% hint style="info" %} Stoïk Protect tiene una **NIS2** evaluación dedicada en la **Cumplimiento** pestaña. Aún no hay una evaluación de DORA en el producto. DORA y NIS2 se solapan mucho en las medidas técnicas, y para las entidades financieras DORA sustituye los requisitos equivalentes de NIS2 (NIS2, art. 4). Por eso, la evaluación de NIS2 sigue siendo un punto de partida útil para un análisis de brechas. {% endhint %} ## ¿A quién afecta DORA? DORA se aplica a la mayoría de las entidades financieras reguladas: bancos, entidades de pago y de dinero electrónico, empresas de inversión, gestoras de activos, aseguradoras y reaseguradoras, proveedores de servicios de criptoactivos y otras. Algunas entidades están **exentas**. La principal exención es para los intermediarios de seguros y reaseguros que sean microempresas, pequeñas o medianas empresas (art. 2(3)). Las entidades más pequeñas dentro del ámbito también pueden aplicar un **marco simplificado de gestión de riesgos TIC** (art. 16). Si no estás seguro de si DORA se aplica a ti, pregunta a tu responsable de cumplimiento o a tu supervisor (ACPR o AMF en Francia). ## Cómo se relaciona Stoïk Protect con DORA DORA tiene cinco pilares. Stoïk Protect contribuye a cuatro de ellos. ### 1. Gestión de riesgos TIC (capítulo II, artículos 5 a 16) Este pilar te pide conocer tus activos, encontrar vulnerabilidades, proteger tus sistemas, detectar anomalías y formar a tu personal. | Herramienta de Stoïk Protect | Requisito de DORA con el que ayuda | Pruebas que puedes mostrar | | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Escaneo externo** | Inventario de activos TIC expuestos a Internet (art. 8(1), 8(4)). Identificación continua de vulnerabilidades y ciberamenazas (art. 8(2)). Supervisión de los sistemas TIC (art. 9(1)). | Informes de escaneo con fecha y un historial de vulnerabilidades y sus correcciones | | **Análisis de Active Directory** | Acceso limitado a lo que cada rol necesita (art. 9(4)(c)). Autenticación fuerte (art. 9(4)(d)). Detección de cuentas privilegiadas, inactivas o mal configuradas. | Informe de configuración de AD y lista priorizada de hallazgos con seguimiento de correcciones | | **Análisis en la nube** (AWS, Azure, GCP) | Seguridad y resiliencia de los sistemas, y prevención del acceso no autorizado y de fugas de datos (art. 9(2), 9(3)). Detección de errores de configuración en tu parte de la nube, donde sigues siendo plenamente responsable (art. 28(1)). | Informe de postura en la nube por entorno | | **Supervisión de credenciales** | Protección frente al acceso no autorizado (art. 9(3)(b)). Detección de cuentas comprometidas antes de que se utilicen (art. 10(1)). | Lista de credenciales filtradas detectadas y contraseñas rotadas | | **Email Security** | Seguridad de los canales de transferencia de datos (art. 9(3)(a)). Menor riesgo de acceso no autorizado y fraude (art. 9(3)(b)). | Estadísticas sobre amenazas bloqueadas | | **MDR** | Detección 24/7 de actividad anómala en endpoints (art. 10(1)). Recursos suficientes para supervisar anomalías y ciberataques (art. 10(3)). Contención rápida (art. 11(2)). | Informes de actividad, alertas gestionadas, tiempos de respuesta | | **XDR** | Varias capas de control, umbrales de alerta y alertas automáticas (art. 10(2)), en VPN, firewall y datos en la nube. | Reglas de detección e historial de alertas | | **Formación** | Concienciación obligatoria sobre seguridad TIC para todo el personal (art. 13(6)). Formación regular del órgano de administración (art. 5(4)). | Tasas de finalización y certificados de los cursos | | **Simulación de phishing** | Programas de concienciación (art. 13(6)). Aprender de las amenazas observadas (art. 13(1)). | Tasas de clic, envío e informe por campaña, con tendencias a lo largo del tiempo | ### 2. Gestión e información de incidentes TIC (capítulo III, artículos 17 a 23) | Servicio de Stoïk | Requisito de DORA con el que ayuda | Pruebas que puedes mostrar | | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | **MDR / XDR** | Detección y registro de incidentes (art. 17(2), 17(3)). La detección temprana importa porque los plazos de notificación de DORA empiezan desde que el incidente se clasifica. | Historial de alertas e incidentes | | **Botón de informar phishing** | Una forma sencilla para que los empleados informen de correos sospechosos, que alimenta tu proceso de detección de incidentes (art. 17(3)). | Correos informados y cómo se gestionaron | | **Stoïk CERT** (respuesta a incidentes 24/7, incluida con el seguro de Stoïk) | Respuesta y recuperación (art. 11). Revisión posterior al incidente y análisis de causa raíz (art. 13(2)). Aportación técnica para los informes de incidentes graves (art. 19(4)): notificación inicial, informe intermedio e informe final. | Informe de incidente con cronología, indicadores de compromiso, causa raíz y acciones tomadas | ### 3. Pruebas de resiliencia operativa digital (capítulo IV, artículos 24 a 27) DORA exige un programa de pruebas, revisado al menos una vez al año, que incluya explícitamente **evaluaciones y escaneos de vulnerabilidades** (art. 25(1)). * **Escaneo externo, escaneo de Active Directory y escaneo en la nube** te proporcionan evaluaciones periódicas de vulnerabilidades que alimentan este programa (art. 24(6), 25(1)). * **Las simulaciones de phishing** son una forma de pruebas basadas en escenarios de ingeniería social (art. 25(1)). > Las pruebas de penetración basadas en amenazas (TLPT, art. 26 y 27) solo son obligatorias para las entidades financieras designadas por su supervisor. Stoïk Protect no las proporciona. ### 4. Riesgo TIC de terceros (capítulo V, artículos 28 a 44) Sigues siendo plenamente responsable de tus obligaciones de DORA cuando utilizas un proveedor de servicios en la nube (art. 28(1)). **Análisis en la nube** te ayuda a controlar la parte de ese riesgo que depende de cómo *tú* configuraste tu entorno. No **lo** sustituye el registro de información ni las cláusulas contractuales obligatorias con tus proveedores TIC (art. 28(3), art. 30). ### 5. Intercambio de información (artículo 45) Este pilar es opcional según DORA. Stoïk Protect no lo cubre directamente. ## Qué sigue siendo tu responsabilidad Stoïk Protect te ofrece herramientas y pruebas. Tu organización sigue siendo responsable de lo siguiente: * **Gobernanza.** Tu órgano de administración tiene la responsabilidad final sobre el riesgo TIC y debe aprobar el marco (art. 5(2)). * **Informes oficiales.** Notificas a tu supervisor los incidentes graves (art. 19). El Stoïk CERT te ayuda a preparar el contenido técnico. * **Copias de seguridad y continuidad del negocio.** Tus políticas de copia de seguridad, restauración y continuidad del negocio o recuperación ante desastres, y sus pruebas (art. 11, 12). * **Registro y contratos con proveedores TIC** (art. 28(3), 30). * **Política de cifrado** (art. 9(4)). * **TLPT**, si tu supervisor te ha designado (art. 26, 27). ## Para empezar 1. Abre **Stoïk Protect** y comprueba qué herramientas ya están activas para tu organización. 2. Activa las herramientas que se ajusten a tus brechas. External Scan, Active Directory Scan, Training y la simulación de phishing son las victorias más rápidas para obtener pruebas de DORA. 3. Completa la **evaluación NIS2** en la **Cumplimiento** pestaña para obtener una visión estructurada de tus medidas técnicas. 4. Exporta los informes de cada herramienta y añádelos a tu documentación de DORA. {% hint style="warning" %} Este artículo ofrece orientación general, no asesoramiento jurídico. Las referencias son a los textos de la UE: el Reglamento (UE) 2022/2554 (DORA) y sus reglamentos delegados (UE) 2024/1774 y (UE) 2025/301. El alcance exacto de cada servicio depende de tu contrato. Para tus obligaciones específicas, pregunta a tu responsable de cumplimiento o a tu supervisor. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-center-en-es/incorporacion/compliance/dora.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.