Trust & security — what we run, where we run it

TracePass is a Bulgarian-registered company building a Digital Product Passport platform for EU compliance. We process customer product data on EU infrastructure with documented sub-processors. Customer is the data controller; TracePass is the processor.

This page is the single procurement reference for our data path, security controls, liability terms, and interoperability conformance. Updated on every meaningful change; see the date stamp at the foot.

Production data resides on EU infrastructure. The application back-end runs on Hetzner Falkenstein; the marketing front-end on Vercel EU edge regions; the primary database on MongoDB Atlas in the eu-west-1 (Frankfurt) region; file storage on Cloudflare R2 EU regions.

AI processing for category extraction and translations is invoked on customer demand only and is governed by an explicit DPA with Anthropic. No customer data is shared with third parties outside the documented sub-processor list.

• Application back-endIn place

  Hetzner CX22, Falkenstein, Germany

• Marketing front-endIn place

  Vercel EU edge regions

• Primary databaseIn place

  MongoDB Atlas, eu-west-1 (Frankfurt)

• File storageIn place

  Cloudflare R2, EU regions

Every entity that processes customer data on our behalf is listed below. Additions to this list trigger advance notification per Article 28 GDPR with a reasonable window for objection. Removals (a sub-processor sunsets) are documented retrospectively here and through customer email.

Standard processor DPA available on request before customer data flows. Breach notification SLA: 72 hours from confirmed incident.

Default-secure infrastructure choices plus application-level controls. Encryption at rest is provided by every storage sub-processor; TLS 1.3 is enforced for all customer traffic. Identity is custom JWT + bcrypt + single-use refresh-token rotation; access controls are role-based (owner, admin, editor, viewer) with rate limiting on every authentication path.

• Encryption at restIn place

  MongoDB Atlas, Cloudflare R2 — provider-default AES-256

• Encryption in transitIn place

  TLS 1.3

• AuthenticationIn place

  JWT (HS256, 15 min) + refresh-token rotation (30 d, single-use, max 5 per user)

• Role-based access controlIn place

  owner > admin > editor > viewer; per-route enforcement

• Rate limitingIn place

  Login (5/15min/IP), registration (5/min/IP), file upload (60/min/company), v1 API (per plan)

• Database backupsIn place

  30-day point-in-time recovery on MongoDB Atlas; restore-tested on a recurring schedule

• Audit logsIn place

  Every passport edit recorded with timestamp, actor, and field-level diff; surfaced in the dashboard timeline

• Security headersIn place

  X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy

Standard liability cap is 12× monthly fees. Enterprise customers can negotiate a 24× rider for higher exposure profiles. Indemnification carve-outs cover third-party intellectual-property claims and regulatory penalties traceable to vendor error.

Errors & Omissions (E&O) insurance is in progress — quote in flight, expected to close shortly. Cap will be published here once the policy binds.

• Standard liability capIn place

  12× monthly fees

• Enterprise riderIn place

  24× monthly fees, available on Enterprise contracts

• E&O insuranceIn progress

  Quote in flight; cap will be published here once policy binds

• Master Services AgreementIn place

  Substantive clauses live in our public Terms of Service (§10 cancellation + 30-day resolver grace, §11 split SLA, §12 customer-as-controller, §13 source-code escrow on Enterprise). Enterprise customers can negotiate addenda (custom SLA, liability rider, escrow triggers) on top of the standard ToS.

Conformance against published interoperability standards — what's tested, what's documented, what's still pending. "We follow the spec" is not a conformance claim; published test results and documented field-level alignment are.

• GS1 Digital Link conformanceIn place

  Functional resolver behaviour self-tested against the GS1 Digital Link v2.0 spec — service-description endpoint, GTIN/serial path resolution, JSON-LD content negotiation, linkset+json output, Vary headers, 404 on unknown URLs. Reproducible script ships at scripts/gs1-conformance-check.ts (committed to the platform repo); customers and auditors can run it against any TracePass-hosted resolver. External test against GS1's hosted reference suite is scheduled separately.

• Schema.org JSON-LDIn place

  Emitted on every public page (home, category, resources, regulatory matrices, buyer's guide). Validated against Google Rich Results Test.

• JSON-LD content negotiation on passport URLsIn place

  Public passport URLs return application/ld+json when the request Accept header explicitly prefers it; HTML otherwise. Same URL contract — no separate endpoint to discover. Implemented via Next.js middleware rewriting to a JSON-LD route handler that serves the same payload as the embedded <script> tag.

• CIRPASS vocabulary alignmentIn place

  Per-template field-level alignment documented; gaps named explicitly with target version.

• GS1 GLN structural support — multi-role economic operatorsIn place

  Every passport carries a structural parties block keyed by economic-operator role (manufacturer / importer / authorised representative / distributor / recycler / producer-responsibility organisation). GLNs are validated 13-digit GS1 identifiers (mod-10 check digit) and emitted in both gs1:partyGLN (GS1 Web Vocabulary) and schema:identifier propertyID GS1:GLN (schema.org mirror). Per-category required-role enforcement matches each regulation (Battery 2023/1542 Articles 47–50: manufacturer + recycler + PRO; PPWR 2025/40 Article 11: manufacturer + PRO; Toy Safety Article 4: manufacturer + importer for non-EU). Suppliers without a GLN can record a legacyOperatorId (VAT / EORI / national tax ID) instead — every party stays traceable. Available via dashboard editor, v1 API (PATCH /api/v1/passports/:id/parties/:role), and CSV bulk import (dotted-key columns).

• Public OpenAPI 3.1 specificationIn place

  Hand-written OpenAPI 3.1 spec covering every v1 REST endpoint (19 paths, 23 operations across passports, products, exports). Published at /openapi.yaml with a JSON mirror at /openapi.json — no NDA, no signup wall. Drops directly into Postman / Insomnia / Bruno or any openapi-generator client target. Worked examples in curl / TypeScript / Python live alongside each endpoint at /docs. Read-and-write coverage is symmetrical with the dashboard — anything you can do in the UI you can drive through the API.

Memberships and ecosystem affiliations that anchor TracePass in the EU Digital Product Passport infrastructure. There is no official EU "approved DPP vendor" registry today — the EU Central DPP Registry is scheduled to go live 19 July 2026 alongside ESPR full application, and the technical specification for vendor integration is still being published in tranches. Until then, the legitimate signals are: GS1 (the identifier-allocation authority), CIRPASS / CIRPASS-2 (the EU-funded coordination action preparing the registry), and the Battery Pass project (industry consortium for the 2027 battery-passport deadline).

We list each affiliation honestly: in-place means the membership / participation is active and verifiable; in-progress means we've applied and are waiting on confirmation; pending means we plan to apply but haven't started. Procurement buyers should treat "pending" the same way they treat any roadmap claim — a stated intent, not a delivered result.

• GS1 Bulgaria — national GS1 member organisationPending

  GS1 is the global standards organisation that allocates GTINs and maintains the GS1 Digital Link URI shape that every TracePass passport QR code uses (/p/01/<GTIN>/21/<serial>). Becoming a GS1 Bulgaria member is the legitimate path to allocating real GTIN ranges for our customers' products at scale, and grants reciprocal access to GS1 Germany / GS1 Italy / etc. when operating across the EU. Application pending.

• CIRPASS-2 — EU-funded Coordination and Support ActionPending

  CIRPASS-2 is the EU Horizon-funded coordination action preparing the technical infrastructure, governance framework, and pilot deployments for the EU Digital Product Passport ecosystem. Participating organisations contribute to working-group output and signal industry-membership status that procurement buyers recognise as legitimate. Application pending.

• Battery Pass project — industry consortiumPending

  BMWK-funded German industry consortium publishing content guidance and reference architecture for the EU Battery Passport (mandatory February 2027 under Regulation (EU) 2023/1542). Member network includes VDMA, Audi, BASF, Circulor and others. Relevant primarily when our customer mix includes EV / industrial / LMT battery manufacturers. Engagement pending — will outreach when our battery-category customer pipeline justifies the membership fees.

• EU Central DPP Registry integrationPending

  The EU Central DPP Registry is scheduled to go live 19 July 2026 alongside the full application of ESPR (Regulation (EU) 2024/1781). It will at minimum hold a list of unique product identifiers and data carrier URLs to enable cross-border passport resolution. TracePass will integrate as a service provider on behalf of customers — writing UPIs and resolver URLs to the registry. The technical API specification has not yet been published; integration work is gated on that publication. Watch the European Commission's DPP page for the spec release.