Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
DORA y la storefront: por qué el Composable Commerce se está convirtiendo en una decisión de compliance en el e-commerce financiero
La mayoría de los programas regulatorios impactan en el negocio por oleadas. Primero llega la lectura inicial del equipo jurídico. Luego el memorándum de políticas. Después la revisión de arquitectura, en la que alguien dibuja un diagrama en una pizarra y cae en la cuenta, en silencio, de que el stack actual no va a aguantar. Con el Digital Operational Resilience Act, el marco de la Unión Europea para la capacidad del sector financiero de resistir y recuperarse de las interrupciones en las TIC, ese momento de pizarra ya ha llegado para un abanico amplio de organizaciones: bancos tradicionales que amplían sus storefronts direct-to-consumer, aseguradoras que venden pólizas online, fintechs que operan marketplaces regulados y proveedores de embedded finance que impulsan productos de crédito y seguro en el momento del checkout.
Lo que sorprende a muchos de estos equipos es que DORA no afecta solo al back office. Llega hasta la storefront, el CMS headless y la capa de entrega de contenido que los clientes ven realmente. La buena noticia es que la decisión arquitectónica que muchas organizaciones vienen tomando por razones puramente comerciales en los últimos años, el paso al Composable Commerce, es justo el tipo de decisión estructural que DORA premia de forma silenciosa.
Este artículo explica cómo DORA plantea la relación entre una entidad financiera regulada y su proveedor de plataforma de frontend, por qué las arquitecturas Composable se traducen en un perfil de riesgo TIC medible y más bajo, y qué pasos concretos debería dar un responsable digital en el próximo trimestre para estar preparado ante las preguntas que auditores y autoridades de supervisión ya están planteando.
Qué te está pidiendo DORA en realidad
Si retiras el lenguaje jurídico, DORA se reduce a una única exigencia: demuestra que tu negocio puede seguir operando, o recuperarse rápido, cuando algo falla en tus tecnologías de la información y la comunicación. Esa demostración tiene que estar documentada, probada y anclada contractualmente en toda tu cadena de suministro TIC. Eso incluye sistemas evidentes como las plataformas de core banking y de pagos, pero también los sistemas con los que tus clientes interactúan de verdad: tu storefront, tu capa de entrega de contenido, tu motor de búsqueda, tu infraestructura de personalización.
Dos ideas de DORA importan especialmente a los responsables digitales. La primera es el registro de información exigido por las Normas Técnicas de Ejecución. Toda entidad financiera debe mantener un inventario completo de cada acuerdo con terceros proveedores de TIC, clasificado por criticidad y con metadatos contractuales y técnicos detallados. La segunda es el marco de riesgo de terceros proveedores de TIC de los artículos 28 a 30, que fija los estándares mínimos sobre cómo contratas con los proveedores, cómo supervisas su desempeño y cómo respondes cuando fallan.
Para cualquier responsable del canal digital, esto significa que tu proveedor de storefront ha dejado de ser una decisión de marketing. Es una entrada en un registro regulatorio. Y tu contrato con ese proveedor tiene que parecerse muy poco al tipo de acuerdo marco de servicios que resultaba aceptable hace cinco años.
Crítico frente a no crítico: la primera pregunta que conviene responder
DORA distingue entre terceros proveedores de TIC críticos y ordinarios. Los proveedores críticos están sujetos a la supervisión directa de las autoridades europeas, a pruebas de resiliencia más rigurosas y a restricciones contractuales más estrictas. Los proveedores ordinarios siguen teniendo obligaciones relevantes, pero el régimen es proporcionado.
Una plataforma de storefront, en la mayoría de los casos, no es un tercero proveedor de TIC crítico. Sirve contenido. Renderiza el detalle de producto. Convierte material de marketing en píxeles. No custodia saldos. No autoriza transacciones. No ejecuta comprobaciones de prevención de blanqueo de capitales. El desacoplamiento del frontend respecto de los sistemas centrales es precisamente lo que permite a las entidades financieras argumentar, de forma creíble, que la capa de storefront forma parte de la superficie de cara al cliente, pero no del tejido transaccional regulado.
Existen, sin embargo, casos límite en los que la clasificación cambia. Una storefront que da servicio a un portal autenticado de una aseguradora digital, que acepta la presentación de siniestros, que muestra documentos contractuales o que guía a los clientes por flujos de onboarding sujetos a KYC tiene otro aspecto a ojos de un supervisor. La clasificación no la determina lo que el proveedor es, sino lo que la función hace dentro de tu modelo de negocio.
Por eso, el primer trabajo de cualquier equipo que inicie una evaluación DORA es un inventario funcional honesto. Enumera todas las funciones de cara al cliente que ofrece tu storefront. Clasifica cada una por su impacto en caso de indisponibilidad, no desde la óptica del marketing, sino desde la de un informe de incidente relacionado con las TIC según el artículo 19.
Por qué la arquitectura es la mayor palanca de resiliencia de la que dispones
La arquitectura de tu canal digital no es una decisión estética. Es una decisión de riesgo. Y en ese terreno, la diferencia entre un stack heredado monolítico y una arquitectura de Composable Commerce se vuelve muy tangible.
Una plataforma monolítica une frontend, lógica de negocio, persistencia de datos e integraciones en una misma base de código. Cuando algo falla o se ve comprometido, el radio de impacto es amplio. Recuperarse implica revertir, restaurar o reiniciar grandes partes del sistema. Probar un componente suele exigir probar el conjunto entero. Documentar el riesgo ante el regulador significa documentar un único enredo gigante.
Una arquitectura de Composable Commerce trata cada capa como un componente independiente y sustituible, conectado mediante APIs. Tu storefront habla con tu proveedor de identidad, con tus sistemas de cuentas, con tu pasarela de pago y con tu CMS de forma independiente. Si tu proveedor de storefront sufre una caída, tu sistema de core banking permanece intacto. Si falla tu componente de búsqueda, el resto del customer journey continúa. Cada componente puede probarse, sustituirse y auditarse por separado.
Este aislamiento no es un argumento de marketing. Es, en el lenguaje de DORA, una contribución estructural a la resiliencia operativa digital del artículo 6. Tres propiedades marcan la diferencia:
- Límites de responsabilidad claros que encajan de forma limpia con el marco de gestión de riesgos TIC que, de todos modos, tienes que mantener.
- Recuperabilidad independiente de los componentes, lo que elimina los fallos en cascada entre sistemas críticos y no críticos.
- Control de seguridad granular, porque cada componente lleva su propio modelo de amenazas en lugar de esconderse tras un perímetro de seguridad monolítico.
No es casualidad que estas propiedades sean también las que permiten a tu equipo publicar más rápido y responder a los cambios del mercado. La conversación sobre DORA simplemente les pone un nombre regulatorio.
Qué exigir a tu proveedor de storefront
Los artículos 28 a 30 de DORA fijan los elementos contractuales mínimos para los acuerdos con terceros proveedores de TIC. Incluso cuando tu plataforma de storefront no es crítica, deberías esperar lo siguiente de cualquier proveedor que se tome en serio dar servicio a entidades reguladas:
Un registro completo de activos de información. Tu proveedor debería mantener un inventario documentado de su propia infraestructura, subencargados y dependencias, y debería facilitarte los datos que necesitas para alimentar tu propio registro de información.
Gestión de incidentes definida con plazos estrictos. Cuando algo va mal, tienes horas, no días, para presentar la notificación inicial que exige DORA. Un proveedor sin vías de escalado claras ni tiempos de respuesta anclados en un SLA hace que ese plazo sea imposible de cumplir.
Pruebas de resiliencia documentadas. El escaneo diario de vulnerabilidades, las pruebas de penetración al menos anuales, los sistemas de detección de intrusiones y los ejercicios periódicos de continuidad de negocio son ya expectativas de partida. Pide los informes de las pruebas, no solo las certificaciones.
Preparación contractual. Tu proveedor debería tener ya preparados anexos DORA que cubran los elementos obligatorios del artículo 30: descripciones precisas del servicio, objetivos de rendimiento, derechos de supervisión, obligaciones de notificación de incidentes, acceso para auditorías y una estrategia de salida creíble.
Transparencia sobre geografía y subencargados. Dónde residen tus datos y qué subencargados los tratan se ha convertido en una pregunta con nivel de auditoría. Los proveedores que publican por adelantado su lista de subencargados y sus opciones de residencia de datos te ahorran semanas de llamadas de aclaración.
Alineación con los estándares de referencia. ISO 27001 y SOC 2 Type 2 no bastan por sí solos para satisfacer DORA, pero son bases necesarias. Un proveedor que no los tenga no resulta creíble en esta conversación.
Un plan de seis pasos para evaluar tu capa de storefront
Si tu equipo empieza hoy la evaluación DORA de vuestro canal digital, la siguiente secuencia funciona en la práctica en bancos, aseguradoras y proveedores de embedded finance:
Paso uno: construye un inventario de funciones. Enumera todas las funciones distintas que ofrece tu storefront, desde la navegación de producto hasta la gestión autenticada de la cuenta o la presentación de siniestros. Puntúa cada una por su impacto en caso de indisponibilidad.
Paso dos: dibuja el flujo de datos. Mapea exactamente qué datos se mueven entre tu storefront, tus sistemas centrales, tu proveedor de identidad, tus herramientas de analítica y cualquier servicio de terceros. DORA da un peso enorme a la claridad en esas fronteras.
Paso tres: clasifica cada componente. Una landing page de marketing no tiene el mismo perfil de riesgo que un área autenticada de autoservicio. Trata las clases de riesgo de forma distinta en tus controles y en tus contratos.
Paso cuatro: evalúa a tus proveedores frente a los artículos 28 a 30. ¿Dónde se quedan cortas sus cláusulas contractuales? ¿Dónde cumplen el listón? Documenta las carencias y prioriza las incorporaciones.
Paso cinco: ejecuta un escenario de resiliencia real. Elige una interrupción plausible, tres horas de caída del frontend, un motor de personalización que devuelve datos malformados, una caída regional del CDN, y recorre qué customer journeys fallan y cuáles sobreviven gracias al aislamiento Composable.
Paso seis: mantén el registro de forma continua. DORA no premia la documentación puntual. El registro de información debe reflejar la realidad de forma permanente, incluidos los cambios de subencargados y las actualizaciones relevantes de los servicios del proveedor.
La dimensión transfronteriza importa más de lo que la gente espera
La mayoría de las entidades financieras que operan en Europa atienden a clientes en varias jurisdicciones. DORA es un reglamento armonizado, pero los supervisores nacionales aplican cierto margen de interpretación en los requisitos de resiliencia, en la definición de los incidentes notificables y en el tratamiento de las pruebas de penetración basadas en amenazas (TLPT).
Una storefront Composable ayuda aquí de una forma que las plataformas monolíticas difícilmente igualan. Los elementos específicos de cada país, banners de cookies, verificación de identidad local, divulgaciones de compliance propias de cada jurisdicción, información sobre resolución de disputas en cada idioma, pueden implementarse en la capa de presentación sin tocar la lógica regulatoria del core. Esa separación te da flexibilidad para cumplir con las variaciones nacionales sin reconstruir el stack central cada vez que un supervisor publica nuevas directrices.
Una storefront multimercado no debería ser una idea de última hora. Los equipos que construyen sobre un stack de frontend bien internacionalizadodesde el principio llegan a las auditorías DORA con pruebas concretas de que han diseñado pensando en la diferencia jurisdiccional en lugar de improvisar sobre la marcha.
Preguntas frecuentes
¿Quién decide si mi plataforma de storefront es un tercero proveedor de TIC crítico bajo DORA?
La clasificación la hace la propia entidad financiera, a partir de su propio análisis de riesgo TIC. La pregunta relevante es la criticidad de la función que soporta la plataforma, no la identidad del proveedor.
¿Bastan ISO 27001 y SOC 2 Type 2 para cumplir con DORA?
Son bases necesarias, pero no suficientes por sí solas. DORA impone obligaciones específicas sobre los plazos de notificación de incidentes, el registro de información y unos mínimos contractuales que van más allá de las certificaciones de seguridad habituales.
¿Tenemos que migrar desde una plataforma monolítica para cumplir con DORA?
No necesariamente. El cumplimiento se puede alcanzar mediante una gestión de riesgos sólida y modificaciones contractuales. Sin embargo, el esfuerzo es bastante mayor, porque dispones de menos palancas arquitectónicas para aislar el riesgo y recuperarte rápido. La mayoría de los equipos que usan DORA como catalizador descubren que la migración al Composable Commerce ya estaba en la hoja de ruta por motivos comerciales.
¿Cómo interactúan DORA y el resto de la regulación digital de la UE?
DORA complementa los marcos existentes en lugar de sustituirlos. El Reglamento General de Protección de Datos (RGPD) regula el tratamiento de los datos personales. La Directiva NIS2 aborda la ciberseguridad en un sentido más amplio para las entidades esenciales. Los programas maduros coordinan los tres bajo una estructura de gobernanza unificada, para evitar duplicar esfuerzos y mantener una única fuente de verdad para los registros de proveedores y activos.
¿Qué ocurre si nuestro proveedor de frontend sufre un incidente grave?
Según el artículo 19, estás obligado a notificar a la autoridad competente los incidentes graves relacionados con las TIC en plazos muy ajustados, aunque el problema de origen esté en un tercer proveedor. Por eso tus contratos deben garantizar que el proveedor te avise de inmediato y te facilite la información que necesitas para presentar tu propio informe a tiempo.
Conclusión: la resiliencia es una decisión de arquitectura
DORA no es de esas regulaciones que se resuelven añadiendo un módulo extra o pasando una auditoría puntual. Exige que la resiliencia esté diseñada dentro de la arquitectura de tu canal digital. El Composable Commerce ofrece exactamente eso: interfaces claras, recuperabilidad aislada, control de riesgo granular y cadenas de suministro transparentes.
Para los responsables digitales que están definiendo su estrategia de storefront para 2026 y los años siguientes, DORA se entiende mejor no como un freno al progreso, sino como un argumento regulatorio a favor de la arquitectura que, casi con toda seguridad, ya quieres por motivos comerciales. El frontend ha dejado de ser un accesorio. Es ya una capa regulada por derecho propio, con su propio modelo de amenazas, sus propias expectativas de notificación de incidentes y su propio lugar en tu registro de información.
Habla con nuestro equipo sobre cómo una storefront Composable puede dar soporte a tu marco regulatorio y sobre cómo, como proveedor con sede en Europa, aportamos piezas contractuales y técnicas concretas a tu evaluación DORA.
Más sobre la plataforma Laioutr
Lecturas relacionadas: El caso financiero para invertir en una Composable Frontend Management Platform y Logs de auditoría en Composable Commerce: la columna vertebral del compliance detrás de las storefronts modernas.