Si escribes software dentro de un banco, aseguradora, firma de inversión, institución de pago u otra entidad financiera cubierta por DORA (el Reglamento de Resiliencia Operativa Digital, Reglamento (UE) 2022/2554), la normativa ya está en vigor para tu organización. Si vendes servicios TIC que esas entidades utilizan, la situación es más precisa: DORA supervisa directamente a los proveedores críticos de servicios TIC de terceros designados, mientras que otros proveedores cumplen principalmente con las obligaciones derivadas de DORA a través de los contratos y la diligencia debida que sus clientes (entidades financieras) les transmiten. En cualquier caso, gran parte de la documentación pública trata DORA como un problema de junta directiva y funciones de riesgo: marcos de riesgo TIC, pruebas de resiliencia, notificación de incidentes a supervisores y cláusulas contractuales clave. Esa interpretación es correcta para la mayor parte de la normativa, pero es incompleta para la parte que un ingeniero implementa realmente.
La parte incompleta es el conjunto de decisiones de resiliencia que residen en el repositorio: un circuit breaker eliminado como "código muerto", un período de retención de copias de seguridad reducido para ahorrar almacenamiento, una nueva API de fraude integrada en la ruta de pagos sin entrada en el registro, una comprobación de estado o regla de alerta eliminada porque generaba ruido. Cada cambio parece ingeniería ordinaria. Cada uno de ellos debilita una obligación que DORA establece a nivel de artículo. Esta guía es para desarrolladores que necesitan saber qué artículos aparecen en una pull request, qué forma tienen esos cambios y cómo detectarlos sin convertir cada revisión en un informe legal.
A quién va dirigido (y a quién no)
Eres parte del público objetivo si tu código soporta una entidad financiera cubierta por DORA, o si tu producto es un servicio TIC que esas entidades utilizan en producción (ya sea que seas un proveedor crítico de servicios TIC de terceros designado bajo supervisión directa, o un proveedor vinculado principalmente a través de contratos con clientes). El alcance y la designación bajo la normativa son cuestiones legales y de clasificación de entidades, no algo que decida una revisión de código. Si tu equipo de cumplimiento o legal ya te ha indicado que DORA se aplica (directa o contractualmente), esta guía trata sobre la parte técnica de esa obligación. Si no estás seguro de si estás dentro del alcance, detente aquí y pregúntales: la respuesta incorrecta implica subinvertir en una obligación real o sobreajustar una normativa que no aplica.
Esto no sustituye a un marco de gestión de riesgos TIC, un programa de pruebas de resiliencia, un proceso de notificación de incidentes, un registro de terceros o cláusulas contractuales clave con proveedores TIC. heygrc no gestiona ninguno de ellos. Está diseñado para identificar el momento en que un cambio en una pull request debilita o introduce un control relevante para la resiliencia que esos programas asumen que sigue existiendo.
Los artículos que realmente aparecen en un diff
La mayor parte de DORA nunca aparecerá como una línea de código de aplicación. Lo que sí suele aparecer en una pull request se agrupa en una lista corta de artículos. Art. 9 (protección y prevención): un cambio debilita el control de acceso, el cifrado, la segmentación de red u otra medida que mantiene aislada una función TIC crítica. Art. 10 (detección): se elimina o desactiva el registro, las alertas o la detección de anomalías en los que una entidad confía para identificar un problema TIC de manera oportuna. Art. 11 (respuesta y recuperación): se elimina como limpieza un reintento, circuit breaker, failover, tiempo de espera o ruta de recuperación que mantenía viva una función crítica durante una interrupción. Art. 12 (copias de seguridad y restauración): se reduce el alcance, la frecuencia o las herramientas de restauración de copias de seguridad, o un nuevo almacenamiento crítico se implementa sin ruta de copia de seguridad. Arts. 17 a 19 (gestión, clasificación y notificación de incidentes relacionados con TIC): un cambio elimina la identificación, el seguimiento, el registro o la grabación de incidentes relacionados con TIC (Art. 17), o elimina campos y señales de los que dependen el proceso de clasificación (Art. 18) y la ruta de notificación de incidentes graves (Art. 19). Art. 28 (principios generales para el riesgo de terceros en TIC), incluido el registro de información según el Art. 28(3): un nuevo acuerdo contractual para un servicio TIC se integra en producción sin registrarse en el registro que debe cubrir todos esos acuerdos. Art. 30 (cláusulas contractuales clave): el acuerdo se trata como "otro cliente SaaS" sin referencia al capítulo de cláusulas contractuales para servicios TIC, que es una obligación separada del registro del Art. 28 y el trabajo de gobernanza.
Esas explicaciones son resúmenes en lenguaje claro para ingenieros, no el texto de la normativa. El análisis detallado del marco en /frameworks/dora recorre los artículos de resiliencia con las formas de cambio que los activan. Las páginas de control en código para el Art. 9 (protección y prevención) y el Art. 11 (respuesta y recuperación) muestran diffs prácticos para segmentación aplanada y un circuit breaker eliminado. Esta guía se centra en el grupo de artículos que más sorprende a los ingenieros de producto: Art. 28 y Art. 30, cuando una llamada conveniente a SaaS se convierte en una dependencia TIC de producción.
Ejemplo práctico: un cliente limpio que se convierte en un tercero TIC no registrado
Un equipo de pagos quiere decisiones de fraude más rápidas. Un ingeniero abre una pull request que reemplaza una ruta de reglas internas lenta con un cliente HTTP tipado para una nueva API externa "FraudScore". El cliente tiene tiempos de espera, reintentos con retroceso, mapeo de errores estructurados y una bandera de función. Las pruebas cubren el camino feliz y errores 5xx. Los comentarios de revisión tratan sobre presupuestos de latencia y si la bandera está activada o desactivada por defecto. Nada en el diff parece incorrecto como software: es una integración bien formada.
Lo que la PR no incluye es ninguna actualización al registro de información sobre acuerdos contractuales para servicios TIC (Art. 28(3)), ni ninguna referencia a las cláusulas contractuales clave del Art. 30 que se aplican a los acuerdos de servicios TIC en general (Art. 30(1) y (2)). Ninguna de esas espera a que alguien decida que la llamada es "crítica". Por separado, si esta comprobación de fraude está en la ruta que autoriza pagos, el acuerdo puede soportar una función crítica o importante, lo que puede activar obligaciones adicionales, incluidas las exigencias de estrategia de salida del Art. 28 y la evaluación de riesgo de concentración del Art. 29, así como las cláusulas contractuales mejoradas del Art. 30(3). Implementar el cliente primero y registrar la entrada "más tarde" es cómo una dependencia de producción se vuelve invisible para el programa que debe rastrear todos los acuerdos de servicios TIC.
Esta es la forma que una revisión consciente del cumplimiento está diseñada para detectar: no "¿el cliente HTTP es correcto?", sino "¿este cambio introdujo o reemplazó un servicio TIC de terceros cuyo acuerdo contractual el Art. 28(3) espera que esté en el registro?". Un hallazgo que cite el Art. 28 / Art. 28(3) (y el Art. 30 cuando las cláusulas contractuales son la brecha) no aprueba el proveedor, redacta el contrato, clasifica la criticidad ni decide el riesgo de concentración. Hace visible la obligación de terceros mientras el autor aún tiene la PR abierta, para que los pasos de registro, clasificación y contrato puedan avanzar con el código en lugar de semanas después de que el tráfico de producción dependa del nuevo proveedor.
Qué buscar en la revisión sin convertirse en un experto legal de DORA
Cuando un cambio añade o reemplaza una dependencia saliente que se ejecutará en producción para una función financiera, haz tres preguntas técnicas: ¿el acuerdo contractual para este servicio TIC ya está registrado en nuestro registro de información (Art. 28(3)), incluyendo cómo se clasifica el servicio y si soporta una función crítica o importante; ¿una interrupción de esta llamada degrada un servicio financiero lo suficiente como para que apliquen trabajos de criticidad y plan de salida; y ¿la misma PR (o un cambio vinculado) actualiza la lista de verificación interna o el ticket que tu equipo de riesgo utiliza cuando un nuevo acuerdo TIC se implementa, incluyendo el trabajo de cláusulas contractuales del Art. 30 si esa es la forma en que tu organización lo rastrea. Si la respuesta del registro es "no" o "desconocido", la función está incompleta desde el punto de vista de DORA de terceros, incluso cuando está completa como código. La criticidad cambia cuánto trabajo adicional sigue, pero no decide si el acuerdo pertenece al registro.
Para las salvaguardas de resiliencia que ya posees, la señal es diferente: una PR cuyo resumen es "limpieza", "eliminar código muerto" o "reducir costos" que elimina reintentos, failovers, copias de seguridad, reglas de aislamiento o ganchos de detección en una ruta crítica. Pregunta si el sistema aún cumple con la propiedad de resiliencia que esa salvaguarda proporcionaba. Los Arts. 9, 10, 11, 12 y el grupo de gestión de incidentes en los Arts. 17 a 19 son las citas habituales cuando la respuesta es no. No necesitas citar la normativa. Necesitas nombrar la propiedad y rechazar la fusión hasta que alguien asuma la restauración de la salvaguarda o la documentación de un cambio aceptado a través de tu proceso real de cambios.
Dónde encaja heygrc y el límite de honestidad
heygrc está diseñado para leer cada pull request frente a los marcos que has seleccionado, incluyendo DORA cuando lo tienes habilitado, y para nombrar el artículo que un cambio parece afectar (por ejemplo, Art. 28(3) en un nuevo acuerdo de servicio TIC que falta en el registro, Art. 11 en una ruta de recuperación eliminada). El hallazgo es un comentario de revisión con el artículo adjunto para que el autor y el revisor puedan decidir con toda la información. No certifica el cumplimiento de DORA, no reemplaza tu marco de riesgo TIC, no ejecuta tus pruebas de resiliencia, no presenta tus informes de incidentes, no mantiene tu registro de terceros ni redacta las cláusulas contractuales del Art. 30. Esas siguen siendo obligaciones humanas y organizativas. Una revisión verde de heygrc no es una aprobación supervisora; es una señal temprana y basada en artículos de que un cambio afectó algo que esos programas consideran importante.
Si tu equipo ya utiliza un revisor de errores o calidad en la misma pull request, manténlo. Esas herramientas preguntan si el código es correcto y seguro. Las preguntas de DORA tratan sobre la resiliencia operativa y la obligación de terceros TIC. El cliente FraudScore anterior puede ser limpio, tipado y bien probado, y aún así dejar el Art. 28(3) incompleto. Ejecuta ambas capas; ninguna reemplaza a la otra.