El pasaporte es una promesa.
Así es como la cumplimos.

Las funciones de servidor de la aplicación se ejecutan en Fráncfort (fra1), junto al almacén de datos principal, un clúster Postgres gestionado en AWS eu-central-1 (Fráncfort). El contenido de los clientes, los registros de los tenants y los registros de auditoría se almacenan allí. Las funciones de IA envían el texto con el que trabajan a la API Gemini de Google, que lo procesa en EE. UU.

Los recursos estáticos y las páginas públicas de los pasaportes se sirven desde una red edge global, desde la ubicación más cercana al lector; solo los recursos públicos y no sensibles (logotipos, textos de marketing, HTML de las páginas del resolver) se almacenan allí en caché. Las respuestas autenticadas de la API no pasan por la caché, por política.

Los dominios propios de los tenants (por ejemplo dpp.brand.com) se sirven desde la misma plataforma. No mantenemos ninguna réplica en espera que pudiera trasladar datos almacenados fuera de la UE.

Todas las conexiones con el resolver, la administración de tenants y la API terminan en TLS 1.2 o superior. HSTS se aplica con un max-age de dos años y preload activado. Las páginas se sirven con X-Frame-Options SAMEORIGIN y Referrer-Policy strict-origin-when-cross-origin; una Content-Security-Policy funciona en modo report-only.

En reposo, el proveedor cifra los volúmenes de almacenamiento de Postgres con AES-256. Las credenciales de integración (Akeneo, Centra, Shopify, inriver, Delogue, tokens REST propios) se guardan en un almacén cifrado por tenant; la clave de cifrado se guarda fuera de la base de datos. Las claves de API de LLM que aportan los tenants (BYOK) se cifran del mismo modo.

El inicio de sesión admite enlace mágico por correo electrónico y Google. Las sesiones se guardan en cookies Secure y SameSite=Lax limitadas a nuestro dominio.

Todas las tablas que contienen contenido de clientes están protegidas con Row-Level Security en la base de datos. Un usuario de un tenant nunca puede leer datos de otro tenant: la restricción se aplica en la capa de base de datos, no solo en el código de la aplicación. El acceso del personal se delimita por separado mediante una tabla staff_users y requiere un motivo operativo que queda anotado en el registro de auditoría.

Los roles dentro de un tenant son admin, editor y viewer: un admin gestiona los miembros y todo lo demás, un editor trabaja con pasaportes y datos pero no puede cambiar quién tiene acceso, y un viewer solo lee. Junto a ellos están los roles orientados a las autoridades para el pasaporte público (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). La suplantación por parte del personal solo es posible mediante un flujo firmado y auditado.

Los secretos de la aplicación se guardan exclusivamente en variables de entorno cifradas de la plataforma. Ningún secreto se sube al control de versiones, ningún secreto se registra en los logs, y las claves de API pegadas en un chat se consideran comprometidas y se rotan en el acto.

Cuando un tenant se integra con un sistema externo, la credencial se guarda por tenant en el almacén cifrado descrito arriba. Las rotaciones, caducidades y cambios de alcance se muestran en el panel Integraciones; los fallos de acceso se anotan en el registro de auditoría del tenant.

La base de datos principal se copia de forma continua con recuperación a un momento dado dentro de una ventana móvil. Las instantáneas diarias cifradas se conservan según un calendario adecuado al plan del tenant; la conservación a largo plazo está disponible bajo petición para categorías reguladas.

Para los clientes que necesitan un alojamiento de copia de seguridad independiente (conforme a la EN 18221 §4.5), mantenemos una vía de escritura en paralelo a un nivel de almacenamiento separado, de modo que el pasaporte siga resolviéndose aunque la aplicación principal no esté disponible. La especificación del proveedor de alojamiento de copias de seguridad está disponible para posibles clientes bajo NDA.

El estado de la infraestructura en directo (disponibilidad, incidencias y mantenimiento programado) se publica en status.dppagent.com. Las incidencias pasadas incluyen qué ocurrió, qué cambiamos y qué detectamos la siguiente vez.

Aceptamos informes de divulgación responsable en security@dppagent.com. Los informes se clasifican en un día hábil y se corrigen según un calendario por gravedad. Los investigadores que actúan de buena fe están protegidos frente a acciones legales, se les reconoce si lo piden y no tienen que firmar un NDA para enviar un informe.

Ante incidencias confirmadas que afecten a clientes seguimos un procedimiento documentado de respuesta: primero la contención, notificación al propietario del tenant dentro del plazo fijado en el contrato, informe posterior publicado en la página de estado y corrección de la causa raíz con seguimiento hasta su cierre.

El runtime de DPP Agent y lo que produce se basan en el conjunto de normas del CEN/CENELEC JTC 24 (EN 18216 acceso, EN 18219 identificadores, EN 18221 ciclo de vida y continuidad, EN 18223 estructura e interoperabilidad), el perfil de referencia CIRPASS-2 y los requisitos por campo del ESPR (Reglamento 2024/1781) y del Reglamento de Baterías de la UE (2023/1542). Los datos de los pasaportes se ajustan a GS1 Digital Link con identificadores de aplicación de GTIN, lote, CPV y número de serie.

Como responsable / encargado del tratamiento que opera desde la UE, estamos sujetos al RGPD y ofrecemos bajo petición un contrato de encargo del tratamiento estándar. Los flujos de datos de los clientes están documentados en nuestra lista de Subencargados, que se modifica con 30 días de preaviso cuando hay cambios significativos.

Actualmente no tenemos la certificación SOC 2 ni ISO 27001. Cuando obtengamos una certificación publicaremos aquí el informe y el alcance de la auditoría. Los clientes Enterprise pueden solicitar bajo NDA el paquete actual de revisión de seguridad, el resumen de las pruebas de penetración y la lista de controles internos.