Der Pass ist ein Versprechen.
So halten wir es.

Die Serverfunktionen der Anwendung laufen in Frankfurt (fra1), neben dem primären Datenspeicher, einem verwalteten Postgres-Cluster in AWS eu-central-1 (Frankfurt). Dort werden Kundeninhalte, Mandantendaten und Prüfpfade gespeichert. KI-Funktionen senden den Text, mit dem sie arbeiten, an die Gemini API von Google, die ihn in den USA verarbeitet.

Statische Assets und öffentliche Passseiten werden über ein globales Edge-Netzwerk ausgeliefert, jeweils vom Standort, der dem Leser am nächsten liegt; nur öffentliche, nicht sensible Ressourcen (Logos, Marketingtexte, HTML der Resolver-Seiten) werden dort zwischengespeichert. Authentifizierte API-Antworten umgehen den Cache grundsätzlich.

Eigene Mandanten-Domains (zum Beispiel dpp.brand.com) werden über dieselbe Plattform ausgeliefert. Wir betreiben keinen Standby, der gespeicherte Daten aus der EU verlagern würde.

Alle Verbindungen zum Resolver, zum Mandanten-Admin und zur API enden auf TLS 1.2 oder höher. HSTS wird mit einer max-age von zwei Jahren und gesetztem Preload erzwungen. Seiten werden mit X-Frame-Options SAMEORIGIN und Referrer-Policy strict-origin-when-cross-origin ausgeliefert; eine Content-Security-Policy läuft im Report-only-Modus.

Im Ruhezustand sind die Postgres-Speichervolumes vom Anbieter mit AES-256 verschlüsselt. Zugangsdaten für Integrationen (Akeneo, Centra, Shopify, inriver, Delogue, eigene REST-Tokens) liegen in einem verschlüsselten Tresor pro Mandant; der Schlüssel wird außerhalb der Datenbank aufbewahrt. Vom Mandanten bereitgestellte LLM-API-Schlüssel (BYOK) werden auf dieselbe Weise verschlüsselt.

Die Anmeldung unterstützt Magic Link per E-Mail und Google. Sitzungen werden in Secure-, SameSite=Lax-Cookies gehalten, die auf unsere Domain beschränkt sind.

Jede Tabelle mit Kundeninhalten ist durch Row-Level Security der Datenbank geschützt. Ein Benutzer eines Mandanten kann nie Daten eines anderen Mandanten lesen — die Einschränkung wird auf Datenbankebene durchgesetzt, nicht nur im Anwendungscode. Der Zugriff von Mitarbeitenden ist separat über eine Tabelle staff_users geregelt und erfordert einen betrieblichen Grund, der im Audit-Log festgehalten wird.

Die Rollen innerhalb eines Mandanten sind admin, editor und viewer — ein Admin verwaltet die Mitglieder und alles darunter, ein Editor arbeitet an Pässen und Daten, kann aber nicht ändern, wer Zugriff hat, ein Viewer liest. Daneben gibt es auf Behörden ausgerichtete Rollen für den öffentlichen Pass (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). Ein Handeln im Namen eines Nutzers durch Mitarbeitende ist nur über einen signierten, protokollierten Ablauf möglich.

Anwendungs-Secrets liegen ausschließlich in verschlüsselten Umgebungsvariablen der Plattform. Kein Secret wird in die Versionsverwaltung eingecheckt, keines wird protokolliert, und API-Schlüssel, die in einen Chat eingefügt werden, gelten als kompromittiert und werden sofort rotiert.

Wenn ein Mandant ein externes System anbindet, werden die Zugangsdaten pro Mandant im oben beschriebenen verschlüsselten Tresor gespeichert. Rotationen, Abläufe und Änderungen der Berechtigungen werden im Bereich Integrationen angezeigt; fehlgeschlagene Zugriffe werden im Prüfpfad des Mandanten protokolliert.

Die primäre Datenbank wird fortlaufend gesichert, mit Point-in-Time-Recovery über ein rollierendes Zeitfenster. Tägliche verschlüsselte Snapshots werden nach einem zum Tarif des Mandanten passenden Plan aufbewahrt; eine Langzeitaufbewahrung ist für regulierte Kategorien auf Anfrage möglich.

Für Kunden, die einen unabhängigen Backup-Host benötigen (nach EN 18221 §4.5), schreiben wir parallel in eine getrennte Speicherebene, sodass der Pass auch dann auflösbar bleibt, wenn die primäre Anwendung nicht verfügbar ist. Die Spezifikation des Backup-Host-Anbieters erhalten Interessenten unter NDA.

Der Live-Status der Infrastruktur — Verfügbarkeit, Störungen und geplante Wartungen — wird unter status.dppagent.com veröffentlicht. Frühere Störungen enthalten, was passiert ist, was wir geändert haben und was wir beim nächsten Mal erkannt haben.

Meldungen im Rahmen einer verantwortungsvollen Offenlegung nehmen wir unter security@dppagent.com entgegen. Meldungen werden innerhalb eines Werktags gesichtet und nach einem am Schweregrad ausgerichteten Zeitplan behoben. Forschende, die in gutem Glauben handeln, sind vor rechtlichen Schritten geschützt, werden auf Wunsch genannt und müssen für eine Meldung kein NDA unterzeichnen.

Bei bestätigten Störungen mit Auswirkungen auf Kunden folgen wir einem dokumentierten Runbook für die Reaktion auf Sicherheitsvorfälle: zuerst Eindämmung, Benachrichtigung des Mandanteninhabers innerhalb der vertraglich festgelegten Frist, Nachbericht auf der Statusseite und Behebung der Ursache bis zum Abschluss verfolgt.

Die Runtime von DPP Agent und ihre Ausgabe sind nach der Normenreihe von CEN/CENELEC JTC 24 gebaut (EN 18216 Zugang, EN 18219 Kennungen, EN 18221 Lebenszyklus und Kontinuität, EN 18223 Struktur und Interoperabilität), nach dem Referenzprofil von CIRPASS-2 und den Anforderungen auf Feldebene der ESPR (Verordnung 2024/1781) und der EU-Batterieverordnung (2023/1542). Die Passdaten entsprechen GS1 Digital Link mit den Application Identifiers für GTIN, Charge, CPV und Seriennummer.

Als Verantwortlicher / Auftragsverarbeiter mit Sitz in der EU unterliegen wir der DSGVO und bieten auf Anfrage einen Standardvertrag zur Auftragsverarbeitung an. Die Datenflüsse der Kunden sind in unserer Liste der Unterauftragsverarbeiter dokumentiert, die bei wesentlichen Änderungen mit 30 Tagen Vorlauf angepasst wird.

Wir verfügen derzeit über keine Zertifizierung nach SOC 2 oder ISO 27001. Sobald eine Zertifizierung erreicht ist, veröffentlichen wir hier den Bericht und den Prüfumfang. Enterprise-Kunden können das aktuelle Paket zur Sicherheitsprüfung, die Zusammenfassung des Penetrationstests und die Checkliste der internen Kontrollen unter NDA anfordern.