¿Por qué el email bancario es una preocupación operativa regulada?
Para un banco UE, una EDE (entidad de dinero electrónico), una IPF (institución de pago) o una fintech con licencia, la infraestructura de email que entrega confirmaciones de transacción, alertas de fraude, notificaciones KYC y extractos bancarios cae en el ámbito de DORA (Reglamento (UE) 2022/2554), está bajo NIS2 artículo 21 como proveedor de "entidad importante", y es auditada rutinariamente bajo el SREP de la EBA y por inspecciones in situ del BCE y del Banco de España. Las decisiones de infraestructura que funcionan para un SaaS B2C no funcionan aquí porque la resiliencia operativa, la gestión del riesgo de terceros y las cláusulas contractuales exigidas por los supervisores financieros son específicas y prescriptivas.
¿Qué exige DORA en concreto a tu proveedor de email?
El artículo 30 de DORA exige que los contratos con prestadores externos de servicios TIC incluyan cláusulas específicas: descripción completa de los servicios, ubicaciones de datos y operaciones, acuerdos de nivel de servicio, requisitos de monitoreo y reporting, disposiciones de continuidad de negocio, controles de subcontratación, derechos de auditoría, derechos de salida y portabilidad. El artículo 28 obliga a las entidades financieras a mantener un registro de acuerdos TIC con terceros con campos de información específicos. El artículo 31 cubre la designación de Proveedores TIC Críticos. No somos formalmente CTPP (el umbral está muy por encima de nuestra base actual), pero nuestro DPA Enterprise estándar incluye cada requisito del artículo 30(2) y entregamos los campos del registro del artículo 28 vía export del panel de cliente.
¿Cómo afecta el reporte de incidentes de DORA a tu proveedor de email?
DORA te obliga a clasificar un incidente TIC grave en las 24 horas siguientes a tener constancia de él, a presentar una notificación inicial a tu autoridad competente en las 4 horas siguientes a esa clasificación, un informe intermedio en 72 horas y un informe final con análisis de causa raíz en un mes. El reloj arranca en la clasificación, no en la detección, así que la propia decisión de clasificar tiene que ser rápida y quedar documentada. El RTS 2024/1772 fija seis criterios —clientes afectados, pérdidas de datos, impacto reputacional, duración e indisponibilidad, extensión geográfica y coste económico con umbral de 100.000 euros—, y un incidente es grave cuando cruza dos de ellos, o uno de forma severa. Aquí está el porqué de que esto importe para un proveedor de email. Si dejan de llegar confirmaciones de transacción o prompts SCA y no puedes saber si la causa está en tu lado o en el nuestro, no puedes clasificar, y la ventana de cuatro horas ya está corriendo. Nuestro manejo de incidentes para clientes del sector financiero está construido para alimentar esa ventana en lugar de competir con ella: contacto con un CSM nombrado en 30 minutos desde la detección, una evaluación inicial escrita en dos horas y un informe de incidente escrito en 24 horas, que es el documento que adjuntas a tus notificaciones inicial e intermedia. Tú presentas a través de tu autoridad nacional firmando con tu propio certificado cualificado eIDAS; nosotros aportamos los hechos técnicos en el orden en que los pide la plantilla del RTS 2025/301.
El email transaccional es un servicio TIC que soporta una función importante.
Un error recurrente en el procurement fintech es archivar el email bajo herramientas de marketing. Bajo DORA la prueba es funcional: ¿soporta el servicio una función crítica o importante? El email que transporta prompts de autenticación reforzada de cliente, alertas de fraude y de anomalías de login, confirmaciones de pago y entrega de extractos soporta funciones que un supervisor leerá como importantes, porque un fallo de entrega sostenido tiene impacto directo sobre el cliente y sobre la prudencia. Eso coloca a tu proveedor de email dentro de los acuerdos TIC con terceros que gobiernan los artículos 28 y 30, el mismo régimen de registro y de contrato que aplicas al proveedor de tu plataforma de core banking, dimensionado a su riesgo real. La consecuencia práctica es que el acuerdo no puede ser un contrato SaaS de aceptación con un clic. Necesita las cláusulas del artículo 30(2): descripción del servicio, ubicaciones de datos y de procesamiento, niveles de servicio, monitoreo y reporting, continuidad de negocio, controles de subcontratación, derechos de auditoría y términos de salida y portabilidad. Nuestro addendum DPA Enterprise lleva cada una de ellas como cláusula estándar en lugar de como negociación caso por caso, que es lo que mantiene la revisión legal en una o dos rondas en vez de un trimestre de idas y venidas. Somos igual de claros con lo que no somos: no somos un Proveedor TIC Crítico, porque esa designación la hacen las Autoridades Europeas de Supervisión por motivos de importancia sistémica y nuestra base está muy por debajo. Tus obligaciones del artículo 30 aplican con independencia de nuestro estatus CTPP, así que lo que importa son los términos y no la etiqueta.
Clientes de banca y fintech españoles y europeos.
Servimos a entidades financieras europeas reguladas: entidades de crédito, EDE, empresas de servicios de inversión y proveedores de servicios de pago. Las usan para combinaciones de emails transaccionales bancarios (extractos, confirmaciones de transacción), alertas de seguridad (detección de fraude, anomalías de login), comunicaciones regulatorias (prompts SCA bajo PSD2, divulgaciones MiFID II) y notificaciones operativas (alertas al compliance officer, escalado interno). Todos bajo contratos Enterprise a medida con las cláusulas DORA artículo 30 y los derechos de auditoría detallados.
Encaje con el supervisor español: Banco de España y CNMV.
Para entidades supervisadas en España, las exigencias adicionales habituales son: aprobación previa del Banco de España o CNMV para subcontratación de funciones esenciales (Circular 2/2016 sobre supervisión y solvencia, Circular 5/2020 sobre nuevos canales de comunicación), documentación de la cadena completa de subcontratación bajo el artículo 28.7 de DORA, registro de actividades del tratamiento conforme al RGPD coordinado con el RAT de protección de datos, póliza específica de ciberriesgo. El plan Enterprise incluye preparación de la documentación necesaria para la solicitud de no-objeción al supervisor en 5 días laborables tras petición.
¿Qué necesitas para el Registro de Información de DORA?
El artículo 28 de DORA exige a toda entidad financiera mantener un Registro de Información que describa sus acuerdos TIC con terceros, y presentarlo cada año a la autoridad competente, con el plazo fijado en el 30 de abril. El registro no es un inventario de texto libre. Las Autoridades Europeas de Supervisión publican una plantilla estructurada con campos definidos: identificadores legales del proveedor incluido el LEI, la función soportada y si es crítica o importante, ubicaciones de datos y de procesamiento, fechas de inicio y fin del acuerdo, la cadena de subcontratación y una evaluación de sustituibilidad. Rellenar esos campos para un proveedor de email que esconde su infraestructura tras una descripción genérica de "nube global" es doloroso, porque la mitad de los campos quedan sin respuesta. A los clientes del sector financiero les damos un export del portal pre-mapeado a los campos del registro: nuestra entidad legal y su LEI, las ubicaciones precisas de los datacenters UE en uso para esa cuenta, la lista de subprocesadores con sus roles y la fecha contractual de inicio. Cuando tu equipo de GRC ensambla el envío anual, la fila del email se rellena desde nuestro export en lugar de reconstruirse a partir de tickets de soporte antiguos. Parece un detalle menor hasta que el plazo del 30 de abril está a dos semanas y el registro tiene un hueco donde debería ir el proveedor de email.
Controles de subcontratación: la cadena que de verdad estás firmando.
El RTS de 2024 sobre subcontratación de servicios TIC que soportan funciones críticas o importantes endureció lo que las entidades financieras deben conocer y controlar sobre los proveedores de sus proveedores. Tienes derecho a ver la cadena de subcontratación, a que te notifiquen los cambios materiales antes de que surtan efecto y a oponerte. Para un proveedor de email la cadena es corta pero no está vacía: la conectividad de red aguas arriba, el CDN delante del portal de cliente, el procesador de pagos para la facturación y cualquier feed de terceros de datos semilla o de reputación. Nuestra cadena estándar para cuentas del sector financiero queda escrita en el addendum DPA en lugar de enterrada en una página de subprocesadores que cambia sin aviso. Donde un supervisor nacional restringe subprocesadores con matriz estadounidense para cargas sensibles, podemos enrutar evitando los valores por defecto estadounidenses habituales con un CDN alternativo y gestión de pagos solo-UE, por 499 euros al mes adicionales y unas dos semanas de configuración. Preferimos cotizar eso con honestidad antes que fingir que la configuración por defecto ya satisface una restricción de residencia que no cumple.
¿Cómo se solapan DORA, NIS2 y PCI DSS en el email?
Pocos remitentes regulados están sujetos únicamente a DORA. El artículo 21 de NIS2 añade obligaciones de seguridad de la cadena de suministro y de manejo de incidentes para entidades importantes y esenciales, y el proveedor de email de un banco forma parte de esa cadena. PCI DSS v4.0 convirtió el manejo de DMARC en un requisito para las organizaciones que procesan datos de tarjeta de pago, lo que arrastra la autenticación de email a la conversación sobre datos del titular de la tarjeta. La parte útil es cuánto comparten estos regímenes. Un solo conjunto de controles —DMARC en p=reject, procesamiento fijado a la UE, plazos de incidente documentados, una cadena de subprocesadores auditada y evidencia anual de resiliencia— responde de una vez a las partes de los tres que tocan al email. Estructuramos la cuenta del sector financiero para que los mismos artefactos sirvan a cada presentación: la atestación de resiliencia que producimos cada enero se corresponde con las expectativas de prueba y reporting de DORA, soporta la narrativa de gestión de riesgo de NIS2 y le da a tu evaluador PCI la evidencia de autenticación de email en un solo lugar. El objetivo es dejar de responder las mismas preguntas tres veces, en tres formatos, para tres auditores distintos.
¿Qué se rompe cuando un banco regulado usa un hyperscaler estadounidense?
La comparación honesta vale la pena hacerla, porque los equipos de procurement la piden. SendGrid, Amazon SES, Mailgun y Postmark son remitentes competentes, y para un producto de consumo no regulado son opciones por defecto razonables. El problema dentro de una entidad financiera UE regulada es estructural antes que técnico. Cada uno opera bajo una matriz corporativa estadounidense, lo que convierte a Schrems II en una cuestión de transferencia viva que tu DPO tiene que documentar en vez de zanjar, y que mantiene CLOUD Act y FISA 702 dentro del ámbito de tu evaluación de impacto de transferencia. Sus contratos estándar son de aceptación con un clic y no llevan las cláusulas del artículo 30(2) de DORA; conseguir que se añadan esos términos, cuando es posible, se vuelve una negociación a medida que su equipo legal no está montado para mover deprisa. El soporte es por niveles y por tickets, lo que está bien para una pregunta de configuración y encaja mal cuando corre un reloj de cuatro horas de DORA y necesitas a un ingeniero que sepa qué es un selector DKIM y qué pasa cuando una IP aterriza en una lista de Spamhaus. Nada de esto los hace malos. Significa que el perfil regulatorio y operativo de una entidad financiera supervisada es un problema distinto del que ellos fueron construidos para resolver, y la migración que vemos con más frecuencia es un banco moviendo sus flujos regulados de cara al cliente a infraestructura UE mientras deja el correo interno de bajo riesgo donde ya está.
Salida y portabilidad, por escrito antes de necesitarlas.
El artículo 30 de DORA y las directrices de externalización de la EBA exigen ambos que un contrato para una función importante detalle una estrategia de salida: cómo recuperas tus datos y operaciones, y cómo te mueves a otro proveedor o a una solución interna, sin una brecha de continuidad inaceptable. Para el email eso significa tres cosas concretas. Tus dominios de envío y tus selectores DKIM siguen siendo tuyos y se mueven contigo. Tus listas de supresión, plantillas y datos históricos de eventos se exportan en formatos abiertos. Y la reputación que construiste sobre IPs dedicadas no se evapora a la salida. Nuestro contrato estándar del sector financiero documenta una ventana de salida de 90 a 180 días con pasos de traspaso definidos: un export completo de configuración y datos, un periodo de ejecución en paralelo en el que el proveedor entrante calienta sus propias IPs mientras nosotros seguimos entregando, y un cutover documentado. Lo ponemos por escrito en la firma y no en la terminación, porque una cláusula de salida negociada cuando ya te estás yendo vale muy poco. Un supervisor que revise tus acuerdos con terceros pedirá ver el plan de salida, y deberías poder entregarlo sin redactarlo sobre la marcha.