Het paspoort is een belofte.
Zo houden wij ons eraan.

De serverfuncties van de applicatie draaien in Frankfurt (fra1), naast de primaire gegevensopslag, een beheerd Postgres-cluster in AWS eu-central-1 (Frankfurt). Daar worden klantcontent, tenantgegevens en audittrails opgeslagen. AI-functies sturen de tekst waarmee ze werken naar de Gemini API van Google, die deze in de VS verwerkt.

Statische bestanden en openbare paspoortpagina’s worden via een wereldwijd edge-netwerk aangeboden, vanaf de locatie die het dichtst bij de lezer ligt; alleen openbare, niet-gevoelige bronnen (logo’s, marketingteksten, de HTML van resolverpagina’s) worden daar in de cache bewaard. Geauthenticeerde API-antwoorden slaan de cache volgens beleid over.

Eigen domeinen van tenants (bijvoorbeeld dpp.brand.com) worden door hetzelfde platform aangeboden. Wij houden geen stand-by aan die opgeslagen gegevens naar buiten de EU zou verplaatsen.

Alle verbindingen met de resolver, het tenantbeheer en de API eindigen op TLS 1.2 of hoger. HSTS wordt afgedwongen met een max-age van twee jaar en preload ingesteld. Pagina’s worden aangeboden met X-Frame-Options SAMEORIGIN en Referrer-Policy strict-origin-when-cross-origin; een Content-Security-Policy draait in report-only-modus.

In opslag zijn de Postgres-volumes door de leverancier versleuteld met AES-256. Inloggegevens voor integraties (Akeneo, Centra, Shopify, inriver, Delogue, eigen REST-tokens) staan in een versleutelde kluis per tenant; de versleutelingssleutel wordt buiten de database bewaard. LLM-API-sleutels die de tenant zelf aanlevert (BYOK), worden op dezelfde manier versleuteld.

Inloggen kan met een magic link per e-mail en met Google. Sessies worden bewaard in Secure-, SameSite=Lax-cookies die beperkt zijn tot ons domein.

Elke tabel met klantcontent is beschermd met Row-Level Security in de database. Een tenantgebruiker kan nooit gegevens van een andere tenant lezen — die beperking wordt afgedwongen in de databaselaag, niet alleen in de applicatiecode. Toegang voor medewerkers is apart afgebakend via een tabel staff_users en vereist een operationele reden die in het auditlog wordt vastgelegd.

De rollen binnen een tenant zijn admin, editor en viewer — een admin beheert leden en alles daaronder, een editor werkt aan paspoorten en gegevens maar kan niet wijzigen wie toegang heeft, een viewer leest. Daarnaast zijn er rollen voor het openbare paspoort, gericht op toezichthouders en ketenpartijen (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). Medewerkers kunnen zich alleen via een ondertekend, geaudit proces als gebruiker voordoen.

Applicatiegeheimen staan uitsluitend in versleutelde omgevingsvariabelen van het platform. Geen enkel geheim wordt in versiebeheer vastgelegd, geen enkel geheim wordt gelogd, en API-sleutels die in een chat worden geplakt, worden als gecompromitteerd beschouwd en direct vervangen.

Als een tenant koppelt met een extern systeem, worden de inloggegevens per tenant bewaard in de versleutelde kluis die hierboven is beschreven. Vervanging, verloop en wijzigingen in rechten worden getoond in het paneel Integraties; mislukte toegangspogingen worden in het audittrail van de tenant gelogd.

Van de primaire database wordt doorlopend een back-up gemaakt, met herstel naar elk tijdstip binnen een doorschuivend venster. Dagelijkse versleutelde snapshots worden bewaard volgens een schema dat bij het abonnement van de tenant past; langdurige bewaring is op verzoek beschikbaar voor gereguleerde categorieën.

Voor klanten die een onafhankelijke back-uphost nodig hebben (volgens EN 18221 §4.5), schrijven wij parallel naar een gescheiden opslaglaag, zodat het paspoort bereikbaar blijft, ook als de primaire applicatie dat niet is. De specificatie van de leverancier van de back-uphost is onder NDA beschikbaar voor geïnteresseerden.

De actuele status van de infrastructuur — uptime, incidenten en gepland onderhoud — wordt gepubliceerd op status.dppagent.com. Bij eerdere incidenten staat wat er gebeurde, wat wij hebben veranderd en wat wij de volgende keer hebben gedetecteerd.

Wij nemen meldingen volgens responsible disclosure aan via security@dppagent.com. Meldingen worden binnen één werkdag beoordeeld en volgens een schema op basis van ernst verholpen. Onderzoekers die te goeder trouw handelen, worden beschermd tegen juridische stappen, op verzoek vermeld, en hoeven geen NDA te tekenen om te melden.

Bij bevestigde incidenten met gevolgen voor klanten volgen wij een gedocumenteerd draaiboek voor incidentrespons: eerst indammen, de tenanteigenaar informeren binnen de termijn die in het contract staat, een verslag na het incident publiceren op de statuspagina, en het herstel van de grondoorzaak volgen tot het is afgerond.

De runtime van DPP Agent en de output ervan zijn gebouwd volgens de normenreeks van CEN/CENELEC JTC 24 (EN 18216 toegang, EN 18219 identificatiecodes, EN 18221 levenscyclus en continuïteit, EN 18223 structuur en interoperabiliteit), het referentieprofiel van CIRPASS-2, en de vereisten op veldniveau van de ESPR (Verordening 2024/1781) en de EU-batterijverordening (2023/1542). Paspoortgegevens voldoen aan GS1 Digital Link met Application Identifiers voor GTIN, partij, CPV en serienummer.

Als verwerkingsverantwoordelijke / verwerker die vanuit de EU werkt, vallen wij onder de AVG en bieden wij op verzoek een standaardverwerkersovereenkomst aan. Gegevensstromen van klanten zijn gedocumenteerd in onze lijst Subverwerkers, die bij wezenlijke wijzigingen met een termijn van 30 dagen wordt aangepast.

Wij hebben op dit moment geen SOC 2- of ISO 27001-certificering. Zodra een certificering is behaald, publiceren wij het rapport en de reikwijdte van de audit hier. Enterpriseklanten kunnen onder NDA het actuele pakket van de beveiligingsbeoordeling, een samenvatting van de penetratietest en de checklist voor interne controle opvragen.