Shreeji Doshi está trabajando con nuestro equipo de asesoramiento cibernético como director de gobierno, riesgo y cumplimiento, y es miembro asociado de la Coalición Belga de Seguridad Cibernética. Como parte de la serie de podcasts DORA Talks, Shreeji ha hablado con expertos de Thomas Murray sobre el impacto de la Ley de Resiliencia Operativa Digital de la UE (DORA).
Este artículo se basa en la transcripción de la entrevista de Shreeji con Panos Kiziris. Panos es director de infraestructura de mercado financiero aquí en Thomas Murray y miembro de nuestro Comité de Riesgos. En el episodio, Panos y Shreeji discuten algunos de los desafíos específicos que enfrentan las FMIs en relación con DORA, especialmente en mercados más pequeños, y si podemos esperar que los reguladores ofrezcan alguna prórroga de último minuto en la fecha límite de cumplimiento.
Director
Slovenia specialist
Panos Kiziris
Gracias, Shreeji, por tomarte el tiempo para responder mis preguntas. La Ley de Resiliencia Operativa Digital, DORA, se publicó a finales de diciembre de 2022, pero tiene una fecha límite de implementación a mediados de enero de 2025.
Por lo tanto, eso es menos de 12 meses a partir de hoy, que se acerca rápidamente, y es una cuestión de qué tan preparadas están las diferentes entidades. Y cuando digo diferentes entidades, las que se ven afectadas por ello son todas las entidades financieras que operan dentro de Europa. Eso también incluye a las FMIs, infraestructuras del mercado financiero, ya sean CSD, depositarios centrales de valores, o CCP, contrapartes centrales.
Desde esa perspectiva, desde la perspectiva de una FMI, he estado hablando durante el último año con algunos CSD en Europa, y ha sido una mezcla si soy honesto. La mayoría de las FMIs ya han lidiado con problemas similares, o han implementado un marco de riesgo sólido en general debido a otras regulaciones en Europa, ya sea EMEA o CSDR.
Pero DORA cambia un poco las cosas ahora, supongo, las hace más detalladas o más específicas en ciertos riesgos. Así que mi primera pregunta para ti, Shreeji, sería ‘bien, los CSD tienen cierto marco de riesgo ahora en su lugar debido a CSDR, pero ¿cómo cambia eso debido a DORA?’ ¿Hay ahora requisitos más específicos que vienen?
Shreeji Doshi
Estás en lo correcto cuando dices que hasta cierto punto las FMIs no habrían experimentado un gran impacto por DORA porque ya había principios de gestión de riesgos que les habían sido impuestos por CSDR.
Además, también hubo directrices de 2018 basadas en las directrices de IOSCO, que es la ciberresiliencia era una expectativa de las FMIs. Eso también tenía a los reguladores presionando a los CSD en mercados individuales para que realizaran cierto tipo de ciberresiliencia.
En principio, el impacto sería limitado debido a estos dos aspectos. Sin embargo, por lo que he leído sobre DORA, hay ciertos requisitos que son bastante prescriptivos, no están relacionados con declaraciones generalizadas sobre el nivel de requisito específicamente.
Y un par de ejemplos que vienen a la mente son, en primer lugar, que la gestión de riesgos debe estar bajo una función de control o una función de auditoría. O tienes ciertas cláusulas que deben ir en los contratos de terceros de TIC. Es bastante prescriptivo. ¿Cómo clasificas un incidente significativo?
Ahora, todas estas cosas en cierto modo serían implementadas por las FMIs, pero podrían tener que volver a examinar las regulaciones para asegurarse de que están cubriendo todas sus bases en estos requisitos prescriptivos que surgen de DORA. Para los CSD hay dos requisitos muy explícitos.
Uno de ellos es que informarán los resultados de sus pruebas de continuidad del negocio, es decir, los resultados de las pruebas de continuidad del negocio de tecnología de la información y la comunicación (TIC), a la autoridad competente.
El segundo es que asegurarán que haya un sitio de procesamiento secundario disponible a una distancia geográfica para garantizar la disponibilidad de dos sistemas con capacidades, recursos, funciones y disposiciones de personal ya establecidos. Entonces, estos son dos requisitos específicos de los CSD. Hay un requisito de tener un plan de recuperación de manera que les permita recuperar todas las transacciones en el momento del trastorno para que puedan operar con certeza y completar el asentamiento en la fecha programada.
Panos Kiziris
Como dije, he hablado con algunos CSD en Europa, y han realizado alguna evaluación inicial de brechas. No me han revelado muchos detalles, pero mi entendimiento es que se sienten cómodos con su marco de riesgo actual y, obviamente, han identificado ciertas cosas que necesitan adaptarse, pero creo que hacen eco de lo que acabas de decir: que tal vez en ese marco de riesgo y aspecto de gobierno, podrían no verse tan impactados.
Sin embargo, me pregunto, ¿hay alguna disposición explícita en DORA sobre el apetito por el riesgo cuando se trata de riesgos de TIC? Porque DORA se trata de TIC. Se trata de tecnología de la información y la comunicación. Entonces, ¿les dice a las entidades financieras y a las FMIs ‘tienen que tener este nivel de apetito por el riesgo, o tienen que definirlo de cierta manera, y tiene que ser aprobado por ciertas personas’?
Shreeji Doshi
No da una prescripción exacta sobre cómo definir el apetito por el riesgo. Básicamente, está pidiendo a las organizaciones que, como parte de su estrategia de resiliencia operativa digital, haya un elemento de establecimiento de un nivel de tolerancia al riesgo para el riesgo de TIC, y esto debe estar alineado con ese marco de ERM, mientras que ‘apetito’ está más ampliamente definido.
Si observas ese requisito específico, se desglosa en dos elementos específicos, ¿verdad? Uno es que ahora, desde un punto de vista del riesgo de TIC, tienen que definir la respuesta, pero también tienen que asegurarse de que puedan demostrar que está vinculado al apetito de riesgo general de la organización. Las organizaciones adoptan varias formas para proporcionar esta correlación, pero esto sería algo en lo que alguien tendría que investigar y ver si están cubriendo todos los aspectos.
Además, esto debe ser aprobado por un cuerpo de dirección. Eso es lo que está diciendo. He visto que las responsabilidades de riesgo de TIC recaen en un CISO desde el punto de vista de la aprobación, o una organización podría tener un cuerpo de riesgo de seguridad de la información que lo examine – no es como si estuviera a cargo de un cuerpo de dirección dedicado.
Entonces, si la gestión del riesgo de TIC no está yendo ya a ese nivel, ahora tiene que llegar a ese nivel.
Panos Kiziris
¿Crees que hay casos en el que un CSD pueda no tener a la persona adecuada para aprobar eso? Es posible que no tengan un CISO, estoy tratando de pensar en casos así, pero creo que todos ellos deben tener a alguien en esa posición en este momento.
Solo estoy preguntando si estás al tanto de alguna excepción.
Shreeji Doshi
El CISO estaría ahí, no me imagino que una FMI no lo tenga, porque ya se les había presionado mucho con muchas regulaciones para poner ese rol en su lugar. Pero ¿a quién reporta el CISO y cuáles son los roles y responsabilidades del CISO?
Si el CISO es responsable de gestionar el riesgo de TIC, y debería estar dentro de su ámbito, el CISO tiene que estar bajo una función de control, o una tercera línea de defensa como una función de auditoría interna. Esa línea de reporte tiene que estar absolutamente clara. El CISO no puede tener un reporte dentro de la primera línea, lo que significa que el CISO no puede reportar a un CIO o un CTO, tiene que estar dentro de una función de CRO o una función de auditoría interna.
Panos Kiziris
Mencionaste la respuesta a incidentes. Como con todo en Europa, siempre hay un enfoque variado y algunos CSD pueden hacerlo de manera diferente que otros, más manual o más automática. ¿Hay un requisito específico dentro de DORA sobre la respuesta a incidentes?
Shreeji Doshi
Un par de cosas. Está armonizando cómo clasificas ‘incidente significativo’. Está estableciendo una taxonomía para hacer eso. Entonces, un CSD en, digamos, Bélgica, frente a un CSD en Bulgaria, clasificar un incidente como ‘significativo’ debería significar lo mismo para ambos ahora debido a DORA.
Y creo que, si DORA logra eso, será su gran logro, ya que las autoridades competentes o las autoridades supervisoras verían los incidentes reportados por ellos desde toda Europa a través de la misma lente.
Además, están proporcionando un plazo para informar sobre incidentes significativos, que es bastante prescriptivo. Necesitas darme un informe inicial dentro del próximo período de tiempo. Debes asegurarte de que en 72 horas puedas reportar algo, y así sucesivamente, y también proporcionar tantos detalles como sea posible dentro de este informe, necesitas considerar todos estos aspectos.
Eso es por separado de tu ‘recolección de información’ básica. Eventualmente, eso será beneficioso para todos los Estados miembros de la UE.
Panos Kiziris
Dado que estamos hablando de estos aspectos más técnicos, ¿DORA tiene requisitos específicos sobre pruebas técnicas que las FMIs y las demás entidades financieras deberían estar realizando, por ejemplo, pruebas de penetración?
Sé que la mayoría de los CSD hacen algún tipo de prueba de penetración, pero no se realiza de manera consistente y algunos pueden estar haciéndolo solo antes de aplicar, y cambia todo lo que hacen antes y después de sus respuestas y las formas en que lo hacen son variadas. ¿Hay una forma más consistente descrita en DORA?
Shreeji Doshi
La hay hasta cierto punto, y si un CSD no hace pruebas de penetración periódicas (pentesting) con una frecuencia fija, creo que podría ser un desafío para ellos. Porque hay varias formas de realizar pruebas de resiliencia operativa digital. La prueba de penetración es una de ellas. Hay múltiples otras formas, no se limita solo a las pruebas de penetración. DORA solicita a las organizaciones identificar vulnerabilidades o problemas a través de numerosas pruebas.
Si un CSD no ha madurado lo suficiente como para hacer esto de manera amplia, de manera periódica, podría tener un desafío de cumplimiento. Además, hay otro requisito en torno a las pruebas de penetración basadas en amenazas, lo que significa que tienen que contextualizar vectores de ataque específicos que afecten a esa región específica o ese CSD específico y realizar una prueba para ver cómo reaccionan sus mecanismos de protección y defensa ante tal amenaza.
Supongo que algunos CSD maduros ya están haciendo esto, pero si hay algunos mercados donde el CSD no ha realizado este ejercicio, tendrían que implementar algo pronto.
Panos Kiziris
Son puntos muy interesantes, Shreeji, porque debo admitir que no estaba al tanto de la extensión de las pruebas que se prescriben en DORA.
Esto suena muy sofisticado para algunos de los CSD que conozco, y apuesto a que no están familiarizados con todos estos tipos diferentes de pruebas. ¿Qué tan grande crees que será ese desafío para ellos? ¿Cómo pueden adaptarse? ¿Cómo pueden avanzar con eso?
Shreeji Doshi
Hay un par de formas y DORA proporciona una orientación.
Los reguladores han dicho, bien, podrías tener un equipo de evaluación interno o un equipo de prueba, y hay pautas sobre cuáles deberían ser las calificaciones de dicho equipo de prueba. Además, pueden optar por un proveedor externo, que creo que es un bien bastante común ahora. Hay muchos proveedores que ofrecen este tipo de servicios.
El CSD debería poder seleccionar entre una variedad de dichos proveedores. Entonces, a nivel de ejecución, no es tan difícil abordar esta brecha, pero requeriría alguna inversión, algunas asignaciones presupuestarias para hacer esto de manera continua.
Panos Kiziris
Mencionaste la respuesta a incidentes. Como con todo en Europa, siempre hay un enfoque variado y algunos CSD pueden hacerlo de manera diferente que otros, más manual o más automática. ¿Hay un requisito específico dentro de DORA sobre la respuesta a incidentes?
Shreeji Doshi
Un par de cosas. Está armonizando cómo clasificas ‘incidente significativo’. Está estableciendo una taxonomía para hacer eso. Entonces, un CSD en, digamos, Bélgica, frente a un CSD en Bulgaria, clasificar un incidente como ‘significativo’ debería significar lo mismo para ambos ahora debido a DORA.
Y creo que, si DORA logra eso, será su gran logro, ya que las autoridades competentes o las autoridades supervisoras verían los incidentes reportados por ellos desde toda Europa a través de la misma lente.
Además, están proporcionando un plazo para informar sobre incidentes significativos, que es bastante prescriptivo. Necesitas darme un informe inicial dentro del próximo período de tiempo. Debes asegurarte de que en 72 horas puedas reportar algo, y así sucesivamente, y también proporcionar tantos detalles como sea posible dentro de este informe, necesitas considerar todos estos aspectos.
Eso es por separado de tu ‘recolección de información’ básica. Eventualmente, eso será beneficioso para todos los Estados miembros de la UE.
Panos Kiziris
Dado que estamos hablando de estos aspectos más técnicos, ¿DORA tiene requisitos específicos sobre pruebas técnicas que las FMIs y las demás entidades financieras deberían estar realizando, por ejemplo, pruebas de penetración?
Sé que la mayoría de los CSD hacen algún tipo de prueba de penetración, pero no se realiza de manera consistente y algunos pueden estar haciéndolo solo antes de aplicar, y cambia todo lo que hacen antes y después de sus respuestas y las formas en que lo hacen son variadas. ¿Hay una forma más consistente descrita en DORA?
Shreeji Doshi
La hay hasta cierto punto, y si un CSD no hace pruebas de penetración periódicas (pentesting) con una frecuencia fija, creo que podría ser un desafío para ellos. Porque hay varias formas de realizar pruebas de resiliencia operativa digital. La prueba de penetración es una de ellas. Hay múltiples otras formas, no se limita solo a las pruebas de penetración. DORA solicita a las organizaciones identificar vulnerabilidades o problemas a través de numerosas pruebas.
Si un CSD no ha madurado lo suficiente como para hacer esto de manera amplia, de manera periódica, podría tener un desafío de cumplimiento. Además, hay otro requisito en torno a las pruebas de penetración basadas en amenazas, lo que significa que tienen que contextualizar vectores de ataque específicos que afecten a esa región específica o ese CSD específico y realizar una prueba para ver cómo reaccionan sus mecanismos de protección y defensa ante tal amenaza.
Supongo que algunos CSD maduros ya están haciendo esto, pero si hay algunos mercados donde el CSD no ha realizado este ejercicio, tendrían que implementar algo pronto.
Panos Kiziris
Son puntos muy interesantes, Shreeji, porque debo admitir que no estaba al tanto de la extensión de las pruebas que se prescriben en DORA.
Esto suena muy sofisticado para algunos de los CSD que conozco, y apuesto a que no están familiarizados con todos estos tipos diferentes de pruebas. ¿Qué tan grande crees que será ese desafío para ellos? ¿Cómo pueden adaptarse? ¿Cómo pueden avanzar con eso?
Shreeji Doshi
Hay un par de formas y DORA proporciona una orientación.
Los reguladores han dicho, bien, podrías tener un equipo de evaluación interno o un equipo de prueba, y hay pautas sobre cuáles deberían ser las calificaciones de dicho equipo de prueba. Además, pueden optar por un proveedor externo, que creo que es un bien bastante común ahora. Hay muchos proveedores que ofrecen este tipo de servicios.
El CSD debería poder seleccionar entre una variedad de dichos proveedores. Entonces, a nivel de ejecución, no es tan difícil abordar esta brecha, pero requeriría alguna inversión, algunas asignaciones presupuestarias para hacer esto de manera continua.
Panos Kiziris
Al igual que con otras regulaciones en Europa, esto comienza a sonar como un ejercicio costoso. Y estoy pensando en CSD donde todo el departamento de TI podría ser solo una o dos personas, ¿estamos viendo situaciones en las que los CSD tendrían que invertir más en personas y tecnología debido a DORA?
Shreeji Doshi
Definitivamente habrá una necesidad de invertir en tecnología. Si el tamaño de su equipo de TI o del equipo de seguridad de la información es bastante pequeño, entonces podrían aprovechar la tecnología para aumentar su mano de obra hasta cierto punto, como ejecutar un proceso de gestión de riesgos o ejecutar evaluaciones de riesgos de terceros.
Y definitivamente tendrían que mirar el modelo de suministro. Creo que un punto muy importante que ha traído DORA es que el cuerpo de dirección, del que hablamos antes, también está encargado de asegurar que se asignen suficientes recursos para garantizar que el marco de gestión del riesgo de TIC se implemente adecuadamente. Entonces deberían estar identificando brechas a nivel de recursos, ya sabes, a nivel del cuerpo de dirección y teniendo ese aporte.
Panos Kiziris
Muy interesante. Dado que estamos hablando de personal y presupuesto, sé que algunos CSD en Europa actualmente no gastan tanto en capacitar al personal y especialmente cuando se trata de TI. Podrían capacitar solo al personal de riesgos o a un grupo muy particular de empleados.
¿Está cambiando eso bajo DORA? ¿Hay requisitos específicos sobre capacitación? Y ¿qué pasa con la alta dirección? ¿Está capturada por los requisitos de capacitación?
Shreeji Doshi
Ampliaría el alcance para que no sea solo capacitación, sino más bien conciencia y tener conocimientos sobre riesgos de TIC. Los reguladores esperan cierto nivel de competencia dentro del cuerpo de dirección y las personas encargadas de gestionar el riesgo de TIC, que comprendan el panorama, que comprendan el contexto.
Está trayendo un cierto nivel de conciencia a esas personas. Y si la organización está, odio usar el término, pero ejecutando un ‘ejercicio de marcar casillas’, por ejemplo, realizar una sesión de capacitación cada año, eso no funcionará porque tienen que demostrar que lo que están haciendo es valioso y significativo.
Panos Kiziris
En cuanto a la preparación de las FMIs, ¿deberían estar haciendo algo al mirar a DORA desde el lado opuesto?
Algunas FMIs son ellas mismas proveedores críticos o proveedores de terceros para otras entidades. Entonces, ¿deberían estar considerando eso y cómo deberían responder?
Shreeji Doshi
No se consideran terceros de TIC según DORA. Hay exclusiones específicas dentro de DORA, y esa es una de ellas, esas entidades financieras que brindan servicios de TIC a otras entidades financieras.
Panos Kiziris
Fantástico. Eso está claro. Tenía una pregunta que quizás debería haber hecho un poco antes, sobre la grabación de anomalías y eventos. Y aunque hemos hablado un poco sobre eso, me gustaría ampliar la pregunta porque sabemos que los CSD tienen un registro de riesgos, tienen una matriz de riesgos, monitorean todos los riesgos a los que están expuestos y asignan criticidad, monitorean los incidentes. Entonces, desde una perspectiva de DORA, dentro del marco de DORA, ¿necesitan tener un registro de riesgo diferente solo para estos riesgos de TIC? ¿Pueden ponerlo en su matriz de riesgos general y cómo deben registrar las anomalías, incidentes, eventos que están ocurriendo, y debería hacerse manualmente, automáticamente, pueden simplemente tener una hoja de cálculo?
¿DORA especifica una forma más estricta y estructurada de hacerlo?
Shreeji Doshi
Dividiré la pregunta en un par de puntos. El primero, ¿va a un registro de riesgo empresarial, o a un registro de riesgo de TIC separado? Desde un punto de vista práctico e de implementación, en mi experiencia, los riesgos de TIC se capturan y registran por separado solo por volumen, y habría vínculos con el registro de riesgo empresarial.
Porque si estás diciendo, este es un riesgo de TIC, digamos que es un riesgo de ciberseguridad, este es un riesgo que se presenta debido a la falta de personal calificado. Todos esos riesgos se unirían bajo esa bandera de TIC, pero en términos de la implementación del marco de gestión del riesgo de TIC, es posible que necesites implementar un segundo registro de riesgos porque necesitarías capturar todos estos controles y asegurarte de que se prueben y se midan de manera diferente.
En cuanto a si necesitas hacerlo manualmente o no, DORA no lo dice. Está diciendo que los incidentes se deben registrar en 72 horas, tienes que clasificar los incidentes, tienes que tener un cronograma claro y transparente para comunicar cómo estás lidiando con ese incidente y tienes que proporcionar tantos detalles como sea posible.
Tendrías que tener algún tipo de sistema automatizado, ya sea una hoja de cálculo o cualquier herramienta de GRC, para manejar eso a tiempo.
Panos Kiziris
Eso suena mucho más estructurado de lo que están acostumbrados algunos CSD en Europa. Y puedo ver cómo, en un mundo ideal, esto debería haber sido parte de su marco de riesgo actual. Pero supongo que algunos de ellos se verán en una carrera para hacerlo a tiempo, ¿no es así?
Shreeji Doshi
Diría que, si ya has implementado prácticas de gestión de riesgos de TIC, este sería un proceso relativamente más fácil para ti. La parte del plazo de implementación no es realmente suficiente para que alguien construya un marco de cero y se sienta cómodo con él.
Pero si ya has estado haciendo esto por un tiempo, podrías hacer que se alinee bastante rápido con los requisitos de DORA. Creo que lo que será difícil para las organizaciones es asegurarse de que tienen la estructura de gobierno correcta en su lugar para cumplir con estos requisitos. Y lo que quiero decir con estructura de gobierno, es el nivel de desglose de roles y responsabilidades, asegurándose de que haya un flujo de trabajo adecuado en su lugar.
Panos Kiziris
Shreeji, me has dado una gran visión general de lo que esperar de DORA y cómo deberían prepararse los CSD. Como siempre, es un placer hablar contigo. Espero que podamos hacerlo de nuevo pronto.
Shreeji Doshi
Gracias, Panos. ¡Sí, desde luego! Siempre es un placer hablar contigo.
¿Estás listo para DORA?
Utilice nuestro kit de herramientas de preparación gratuito y fácil de seguir para determinar qué tan cerca está su organización de cumplir con todos los requisitos de la Ley de Resiliencia Operativa Digital (DORA). Una vez completado, le enviaremos un informe gratuito que describe qué tan preparado está para DORA. Puede utilizar nuestros resultados para crear un plan de acción para lograr el cumplimiento antes del 17 de enero de 2025.