El registro de información exigido por el artículo 28(3) de DORA parece un ejercicio de inventario. No lo es. Es una declaración estructurada, en un formato prescrito, de cada acuerdo contractual para el uso de servicios TIC; y como los supervisores lo recogen de forma centralizada, los errores resultan visibles, comparables entre entidades y duraderos.
Ya hemos construido o reparado registros para entidades que van desde pequeñas entidades de pago hasta gestoras de activos medianas. Se repiten los mismos diez problemas.
1. Partir de la lista de proveedores en lugar de la base contractual
El registro se organiza en torno a acuerdos contractuales, no a proveedores. Un proveedor con tres contratos son tres acuerdos. Un contrato que cubre cuatro entidades aparece en cada una de ellas. Los equipos que parten de la lista de proveedores de compras producen un registro con los nombres correctos y la estructura equivocada, y reestructurarlo después cuesta más que construirlo bien.
Empiece por los contratos firmados. Finanzas suele tener una lista mejor que TI.
2. Dejar fuera los acuerdos intragrupo
Los servicios prestados por una matriz o una sociedad hermana son servicios TIC de terceros a efectos del registro. Están dentro del ámbito, necesitan documentación contractual y con frecuencia son las relaciones peor documentadas de la entidad, porque «son internas». Los supervisores han sido explícitos al respecto.
3. Adivinar las funciones soportadas
Cada acuerdo debe vincularse a las funciones que soporta, y cada función debe evaluarse en cuanto a criticidad. La mayoría de las entidades nunca ha escrito su mapa de funciones, así que este se convierte en una lista inventada bajo presión de tiempo por quien esté rellenando la hoja de cálculo.
Haga primero el mapeo de funciones, como ejercicio de negocio con el negocio. Son dos o tres talleres. Sin él, las valoraciones de criticidad carecen de fundamento y todos los campos posteriores heredan el problema.
4. Declararlo todo crítico, o nada
Ambas cosas ocurren y ambas se leen como una falta de evaluación. Si el noventa por ciento de sus acuerdos soporta funciones críticas o importantes, no ha evaluado: se ha cubierto. Si ninguno lo hace, está afirmando que su entidad podría operar sin todos ellos.
La evaluación debe estar razonada y registrada, y el razonamiento importa más que la conclusión.
5. Perderse la cadena de cuarto nivel
Para los acuerdos que soportan funciones críticas o importantes hay que identificar a los subcontratistas de la cadena que prestan efectivamente el servicio. Aquí es donde más fallan los registros, porque la información no está en su contrato: está en el de su proveedor.
Hay que pedirla, y la petición tarda más de lo que el plazo permite si se empieza tarde. Pida pronto, pida por escrito y meta la respuesta en el contrato en la renovación para no tener que volver a pedirla.
6. Identificadores erróneos o ausentes
Los identificadores de entidad jurídica de la entidad y de sus proveedores, y el EUID cuando proceda, son campos obligatorios con formato definido. Un LEI ausente o mal formado provoca un rechazo automático en la validación, y para proveedores pequeños el LEI puede no existir todavía, en cuyo caso alguien tiene que obtenerlo, lo que lleva tiempo y cuesta dinero.
Valide los identificadores en una pasada aparte, antes de pensar en el contenido.
7. Tratarlo como un ejercicio anual
El registro debe reflejar la realidad y se remite al menos anualmente, notificando los cambios sustanciales según se producen. Un registro mantenido una vez al año por el propietario de una hoja de cálculo que desde entonces ha cambiado de puesto se convierte, en cuestión de meses, en un documento que describe mal la entidad ante su supervisor.
La solución es procedimental, no técnica: ningún contrato TIC se firma o renueva sin actualizar el registro en el mismo flujo. Métalo en la lista de comprobación de compras.
8. Planes de salida que no existen
El artículo 28 exige estrategias de salida para los acuerdos que soportan funciones críticas o importantes. El registro le pide declarar si existe una. Responder que sí cuando el «plan de salida» es un párrafo que dice que el contrato puede resolverse con tres meses de preaviso es una declaración inexacta, y fácil de comprobar para un supervisor.
Un plan de salida utilizable nombra la alternativa, indica cómo se extraen los datos y en qué formato, estima tiempo y coste, y se ha probado al menos sobre el papel. Escribir uno para sus tres proveedores más concentrados es una semana de trabajo y es el elemento con más probabilidades de ser examinado.
9. Cláusulas contractuales anteriores a DORA que nunca se corrigieron
El artículo 30 enumera las estipulaciones que deben figurar en los contratos de servicios TIC, con una lista más larga para las funciones críticas o importantes: derechos de acceso, inspección y auditoría, salida y apoyo a la transición, descripción de los niveles de servicio, compromisos de notificación de incidentes, ubicación del tratamiento de los datos. Los contratos heredados rara vez los contienen.
El registro lo pone al descubierto. Usted declara, acuerdo por acuerdo, si esas cláusulas están presentes. Planifique el programa de renegociación antes de completar el registro, porque es el registro lo que hace oficial la brecha.
10. Asignar la propiedad al sitio equivocado
Hemos visto el registro en manos de compras, de TI, de asesoría jurídica y de un jefe de proyecto externo. Funciona mejor bajo la función que ya responde ante el supervisor —riesgos o cumplimiento—, con TI y compras como contribuyentes y un suplente designado.
La razón es sencilla: el registro es una declaración regulatoria. Debería producirlo quien entiende lo que significa firmar una declaración regulatoria.
Cómo es una buena primera pasada
Para una entidad financiera mediana, la forma honesta del trabajo es esta:
- Una semana para establecer el mapa de funciones y el método de criticidad con el negocio
- De dos a tres semanas para reunir la base contractual y los identificadores
- Dos semanas de valoraciones de criticidad, cadenas de subcontratación y ubicación de datos
- Una semana de validación, revisión interna y firma
- En paralelo, un análisis de brechas contractuales que se convierte en un plan de renegociación
De seis a ocho semanas, y un registro que sobrevive a la primera pregunta. Las entidades que lo comprimen en dos semanas suelen producir un fichero que pasa la validación de formato y falla la primera revisión de fondo, lo que cuesta más que hacerlo despacio.
El registro no es el objetivo de DORA. Pero es la parte de DORA que su supervisor lee primero, así que es la parte que marca el tono de todo lo demás.