Qué Esperan los Auditores DORA de Tus Pruebas de Carga

Bajo DORA, la evidencia de pruebas de carga y rendimiento es parte de la revisión de resiliencia.

Para los equipos de cumplimiento e ingeniería en entidades financieras de la UE que necesitan demostrar que sus sistemas soportan el volumen.

La Ley de Resiliencia Operativa Digital (DORA) de la UE se aplica a las entidades financieras desde el 17 de enero de 2025. Establece un único reglamento sobre cómo bancos, aseguradoras, firmas de inversión y sus proveedores de TIC críticos mantienen los servicios digitales operativos durante interrupciones. Las pruebas de resiliencia operativa digital son uno de sus cinco pilares (junto con la gestión de riesgos TIC, el reporte de incidentes, el riesgo de terceros y el intercambio de información), y ese pilar abarca directamente tus pruebas de carga y rendimiento.

Una aclaración primero, porque el acrónimo está sobrecargado. Este artículo trata sobre la regulación de la UE. No trata sobre las “métricas DORA” de DevOps (frecuencia de despliegue, tiempo de entrega y demás). Son DORA completamente diferentes.

El artículo 25 del reglamento enumera los métodos de prueba que debe usar un programa de resiliencia. Las pruebas de rendimiento y las pruebas end-to-end están en esa lista, junto con evaluaciones de vulnerabilidades y pruebas de penetración. Así que cuando un examinador revisa tus pruebas de resiliencia, la evidencia de pruebas de carga y estrés es válida.

La mayoría de la cobertura de DORA online se centra en pruebas de penetración dirigidas por amenazas. Este artículo cubre la obligación más silenciosa: mostrar que tus sistemas se mantienen receptivos bajo volumen, produciendo la evidencia que un auditor realmente pedirá ver, y haciéndolo con una herramienta construida para el trabajo. LoadView es una plataforma de prueba de carga basada en la nube y en navegadores reales, y las secciones siguientes mapean cada ítem de la lista de verificación para revisores DORA a la capacidad de LoadView que lo genera.

Qué Cubre Esta Guía

1. Dónde Encajan las Pruebas de Carga en DORA
2. La Evidencia de Auditoría que un Examinador DORA Espera
3. Cómo LoadView Apoya las Pruebas de Resiliencia Operativa DORA
4. Por Qué los Números de Carga Solo de Protocolo No Sirven en una Auditoría
5. Cómo Producir Evidencia de Pruebas Lista para DORA
6. Conclusión
7. Preguntas Frecuentes

Dónde Encajan las Pruebas de Carga en DORA

DORA está basada en riesgos, no es prescriptiva sobre herramientas. No dice “realiza una prueba de carga de 500 usuarios cada trimestre.” Dice que debes probar los sistemas TIC que soportan funciones críticas o importantes, de forma regular, y actuar según los hallazgos.

Dos artículos tienen la mayor carga para el trabajo de rendimiento:

• Artículo 24 establece los principios generales de prueba. Las entidades financieras deben probar los sistemas y aplicaciones TIC que soportan funciones críticas o importantes al menos una vez al año, usando un enfoque basado en riesgos.
• Artículo 25 enumera los métodos que el programa puede usar. Se nombran explícitamente las pruebas de rendimiento y las pruebas end-to-end.

Para una plataforma de trading, una API de pagos o un portal de banca en línea, “resistir la interrupción” incluye interrupciones por carga: un pico a la apertura del mercado, un aumento en el día de la nómina, una promoción que triplica el tráfico de pagos. Si el servicio se ralentiza o cae bajo volumen, eso es una brecha en la resiliencia operativa. Y DORA espera que la hayas buscado antes de producción, que es donde las pruebas de carga para servicios financieros ganan su lugar en el programa.

Lo que está en juego es práctico, no solo procedimental. Los supervisores pueden exigir a una entidad que remedie brechas de resiliencia que detecten, así que una revisión que detecte un sistema crítico sin pruebas tiende a generar trabajo no planificado en el calendario del regulador, no el tuyo.

La Evidencia de Auditoría que un Examinador DORA Espera

Los examinadores trabajan con evidencia, no con intenciones. Durante una revisión de tus pruebas de resiliencia, espera que busquen artefactos como estos:

La primera fila es donde los equipos pierden más puntos. Sin SLAs de rendimiento documentados, una prueba de carga no tiene una línea de aprobado/reprobado, y un auditor ve un gráfico sin un estándar detrás. Escribe los objetivos primero: tiempo de respuesta P95 por transacción crítica, un límite de tasa de error y la carga máxima que cada sistema debe manejar.

Las filas dos y tres tratan sobre el momento y la severidad. Ejecutar una prueba de carga antes de cada lanzamiento a producción muestra que se revisa el volumen antes de que los clientes usen el código, y adicionar esa revisión a la pipeline de entrega mantiene la coherencia. La prueba de estrés va más allá de la de carga, superando los picos previstos hasta que algo falla, de modo que el punto de ruptura sea un número conocido en lugar de una sorpresa el día de la apertura del mercado.

La fila cuatro es el artefacto que manejan más los examinadores. Un informe con percentiles de tiempos de respuesta, tasas de error y el perfil de carga que los produjo es la evidencia central, y necesita fecha y versión para relacionarse con un lanzamiento específico.

La fila cinco conecta la prueba con una previsión. La documentación de planificación de capacidad indica cuánto margen midió la última prueba y cuándo el crecimiento lo agotará. Las filas seis y siete separan un programa real de uno solo en papel. Cuando una prueba detecta un cuello de botella, el examinador quiere el seguimiento, por eso los informes de LoadView que identifican cuellos de botella de rendimiento hacen la acción específica: qué componente fue lento, qué cambió y el resultado del re-testeo.

Cómo LoadView Apoya las Pruebas de Resiliencia Operativa DORA

Cada fila de esa lista de evidencias se corresponde con algo que LoadView hace directamente. La tabla a continuación compara el artefacto que pide un examinador con la capacidad de LoadView que lo genera, para que el requisito de cumplimiento y la funcionalidad de la herramienta se alineen uno a uno.

Dos detalles de LoadView hacen la mayor parte del trabajo aquí. El primero es que las pruebas se ejecutan en navegadores reales, así que los números de tu informe son los tiempos que un cliente vería realmente, lo que hace que el informe sea creíble como evidencia de resiliencia. El segundo es que todo el flujo está guionado como un recorrido de usuario y no como un conjunto de solicitudes en bruto, por lo que una prueba end-to-end bajo el Artículo 25 de DORA cubre inicio de sesión, transacción y confirmación como lo hace una sesión real. Las siguientes dos secciones cubren cada uno de esos puntos a su vez.

Por Qué los Números de Carga Solo de Protocolo No Sirven en una Auditoría

Una prueba de carga que envía solicitudes HTTP en crudo puede reportar grandes números de rendimiento. Pero para un servicio financiero orientado al cliente, esos números describen el servidor, no al cliente. Se saltan el JavaScript, la verificación antifraude de terceros, el redireccionamiento SSO y la pantalla de confirmación renderizada.

Un examinador que pregunta si los clientes pueden operar bajo carga quiere evidencia sobre la experiencia del cliente, no solo la tasa de solicitudes del origen. Las pruebas de carga en navegador real ejecutan la prueba en instancias reales de Chromium, por lo que los tiempos de respuesta en tu informe son los que un cliente vería. En términos claros, la prueba carga la página como lo haría el navegador del cliente: ejecutando scripts, redireccionamientos y renderizado, en lugar de solo hacer ping al servidor.

Para un banco o proveedor de pagos, esa es la diferencia entre “la API respondió en 200 ms” y “el flujo de inicio de sesión a confirmación tomó nueve segundos porque la llamada para puntuar el fraude se encoló”. Lo segundo degrada el servicio. Y es exactamente lo que una revisión de resiliencia busca, por eso las pruebas de concurrencia de transacciones contra el flujo real del usuario producen evidencia más sólida que un gráfico de rendimiento a nivel de protocolo.

Una herramienta que reporta “100,000 solicitudes por segundo” sin ejecutar la página mide el rendimiento HTTP, no lo que un cliente experimenta en la pantalla de inicio de sesión. Un auditor que revisa la resiliencia orientada al cliente quiere el segundo número.

Las pruebas a nivel de protocolo miden el servidor; las pruebas en navegador real de LoadView miden el flujo de inicio de sesión a confirmación que realiza un cliente.

Cómo Producir Evidencia de Pruebas Lista para DORA

No necesitas una nueva categoría de herramienta para satisfacer este pilar. Necesitas pruebas que se correspondan con la lista de evidencia y un registro que puedas entregar a un auditor. Aquí está la secuencia en LoadView:

1. Escribe los requisitos de rendimiento para cada función crítica. Establece percentiles de tiempos de respuesta y un límite de tasa de error por transacción, haz que los aprueben y ponlos como umbrales de aprobado/reprobado en la prueba para que los resultados se evalúen automáticamente.
2. Graba la prueba como un flujo real de usuario. Usa el grabador EveryStep para capturar el recorrido real (inicio de sesión, transacción, confirmación) clic a clic en un navegador real, luego repítelo bajo carga con pruebas de carga de aplicaciones web en lugar de repetir solo llamadas HTTP en bruto.
3. Prueba hasta el pico esperado y luego más allá. Configura los tipos de curva de carga para mantener usuarios virtuales en el pico previsto durante la prueba de carga y luego una curva escalonada que lo supera para la prueba de estrés, de modo que tengas respuestas guardadas para las preguntas “¿podemos manejar el día?” y “¿dónde fallamos?”.
4. Genera la carga desde las regiones que atiendes. Si tus clientes están dispersos por la UE, ejecuta desde más de 30 zonas de inyección geodistribuida de carga para que el rendimiento se mida donde están realmente los usuarios, no solo desde un centro de datos.
5. Guarda el informe. Exporta los informes de prueba de rendimiento con percentiles, tasas de error, perfil de carga, cascada y sello temporal, y archívalos junto con el registro del lanzamiento. Ese archivo es lo que el examinador lee.
6. Reprueba según un cronograma y tras cambios. Repite al menos anualmente para funciones críticas, después de cualquier lanzamiento que afecte un camino crítico y cuando el crecimiento te acerque al límite de capacidad medido en la última prueba. Programar la ejecución y conectarla a tu pipeline CI/CD mantiene esa cadencia automática en lugar de ser solo un recordatorio de calendario.

De esta forma, la evidencia se genera como un subproducto de pruebas que de todas formas querrías hacer. Como LoadView es totalmente alojado en la nube, no hay infraestructura para levantar o justificar ante un auditor, y los artefactos coinciden con lo que un revisor DORA pide, en el orden que lo pide.

El alcance de DORA también cubre a los proveedores críticos de TIC terceros que usas. Si una pasarela de pagos, un servicio de identidad o una API de datos forman parte de un camino crítico, su comportamiento bajo carga también forma parte de tu panorama de resiliencia, por lo que las pruebas de carga de API en esos puntos mantienen la misma evidencia archivada para servicios que tú no operas directamente.

Ve cómo LoadView produce la evidencia que un examinador DORA solicita. Programa una demostración de LoadView para dimensionar una prueba según tus volúmenes pico y exportar los informes que tus auditores pedirán.

Conclusión

DORA no te entrega una lista de pruebas de carga, pero su pilar de pruebas de resiliencia y los métodos del Artículo 25 hacen que las pruebas de rendimiento y carga formen parte de lo que un revisor puede inspeccionar. Los sistemas que importan son los que soportan funciones críticas o importantes, y el estándar es que continúen atendiendo a los clientes bajo volumen.

Produce los siete artefactos que un examinador espera, basándolos en resultados de navegadores reales en lugar de solo rendimiento a nivel de protocolo, y vuelve a probar conforme crecen los volúmenes. LoadView está diseñado para generar cada uno de esos artefactos a partir de una sola prueba guionada, por lo que una revisión de resiliencia de tus pruebas de rendimiento se convierte en cuestión de entregar registros que ya mantienes.

Preguntas Frecuentes