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

TracePass is a Bulgarian-registered company building a Digital Product Passport platform for EU compliance. The application and its database run on EU infrastructure; our sub-processors are documented below. 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.

The application back-end and the primary database run on Hetzner in Nuremberg, Germany; the marketing front-end runs on Vercel, with its server functions in Frankfurt; file storage and database backups use Cloudflare R2.

AI processing (data extraction from documents and images, including OCR; the research agent; translations) is invoked on customer demand only and is governed by an explicit DPA with Anthropic. No customer personal data is shared with third parties outside the documented sub-processor list. Services used for product lookups, such as web search and public registers, receive product queries, not personal data.

• Application back-endIn place

  Hetzner, Nuremberg, Germany

• Marketing front-endIn place

  Vercel (server functions in Frankfurt)

• Primary databaseIn place

  MongoDB, Hetzner in Nuremberg, Germany

• File storageIn place

  Cloudflare R2

Every entity that processes customers' personal data on our behalf is listed below; services that receive only product queries, such as web search and public registers, are not sub-processors. 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.2 or higher 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 sign-in, registration, password-reset requests and second-factor verification.

• Encryption at restIn place

  File storage (Cloudflare R2) — AES-256. Application database — the database volume is encrypted at rest with LUKS2 (AES-XTS, 512-bit key). Daily logical backups are stored in Cloudflare R2, encrypted at rest.

• Encryption in transitIn place

  TLS 1.2+

• AuthenticationIn place

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

• Multi-factor authenticationIn place

  TOTP (RFC 6238, 6 digits, 30 s), opt-in per user. A company can require it for everyone — an unenrolled member is walked through setup at their next sign-in, so enabling it locks nobody out. Ten single-use recovery codes; an owner or admin can reset a member's factor.

• Role-based access controlIn place

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

• Rate limitingIn place

  Login (20/min/IP + per-user lockout), file upload (60/min/company), v1 API (per plan)

• Database backupsIn place

  Daily automated logical backup to Cloudflare R2 (encrypted at rest), 7-day retention, stored off the database server

• Audit logsIn place

  Every passport edit recorded with timestamp, actor, and field-level diff; surfaced in the dashboard timeline. Every change to a published, suspended, expired or archived passport is also archived as a complete snapshot, sealed with a SHA-256 content hash and recording who made the change; any past version can be retrieved by date (EN 18221:2026, clause 4.2). The public view of each published version is also signed as a W3C verifiable credential (issuer did:web:www.tracepass.eu), returned at the passport URL for Accept: application/vc+jwt.

• Upload scanningIn place

  Every uploaded file — customer documents, supplier evidence, product images, logos — is checked before it is stored: its content must match the declared file type (a renamed executable is refused, as are Office files with macros), and it is malware-scanned before storage. Files are never sent to a third party for scanning. If the scanner is unavailable, the upload is refused rather than stored unscanned

• Security headersIn place

  Content-Security-Policy (enforced, nonce-based on the app; report-only on the marketing site), HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy

• ISO 27001 certificationPending

  Not yet held. The controls above (encryption, access control, backups, audit logging) are the substance an ISO 27001 ISMS formalises, but no certificate has been issued and no audit is in progress. We will pursue certification when enterprise customer demand justifies the audit cost; we won't claim it before a certificate exists. Ask us for the current control documentation in the meantime.

• SOC 2 reportPending

  Not yet held, no audit window scheduled. SOC 2 (Type II in particular) requires an observation period a company of our age and stage has not yet run. Same honesty rule as ISO 27001: we will not represent a SOC 2 report until an auditor has issued one. EU customers are typically served first by our EU-hosted application and database + GDPR processor terms, which are documented above and in the DPA.

Liability and indemnification are as set out in the Terms of Service.

Errors & Omissions (E&O) insurance is not yet in place.

• Liability termsIn place

  As set out in the Terms of Service

• E&O insurance

  Not yet in place; the cover limit will be published here once a policy is bound

• Terms of ServiceIn 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 tools/gs1-conformance-check.ts in the public tracepass-open repo; customers and auditors can run it against any TracePass-hosted resolver, and the current signed-off run against id.tracepass.eu is published alongside this page (9 of 9 checks passing). Not yet tested against GS1's resolver test suite.

• Schema.org JSON-LDIn place

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

• Content negotiation on passport URLs (HTML, JSON-LD, JSON)In place

  Public passport URLs return HTML to browsers, application/ld+json when the Accept header prefers it, and plain application/json when that is requested — EN 18216 makes JSON the mandatory machine-readable format. The machine-readable body carries the EN 18223 passport header (digitalProductPassportId, uniqueProductIdentifier, granularity, dppSchemaVersion, dppStatus, lastUpdated, economicOperatorId) as top-level fields, each emitted only where the data exists. Passport URLs are served over HTTP/2 or later with TLS 1.2+, as EN 18216 requires. One URL for every format — no separate endpoint to discover.

• Data carriers: QR Code and Data Matrix (EN 18220)In place

  A passport's data carrier can be generated as a QR Code (ISO/IEC 18004) or a Data Matrix (ISO/IEC 16022) — the two 2D symbologies EN 18220 permits — encoding the same GS1 Digital Link URL, as SVG or PNG, from the dashboard, the API, the MCP server and the n8n community node. Data Matrix suits small parts and direct part marking. Battery passports stay on QR, which the Battery Regulation specifies.

• Accessible public viewer (EN 301 549 / WCAG 2.1 AA)In place

  EN 18216 requires the human-readable passport to meet EN 301 549. The public viewer passes an automated WCAG 2.1 AA audit (axe: 0 violations) plus keyboard, zoom and text-spacing checks: the page language follows the passport's language, content sits in landmarks, collapsible sections announce their state and keep hidden content out of the tab order, and text contrast meets 4.5:1 even with a customer's brand colours. Not yet reviewed by an external accessibility auditor.

• Not yet built: EN 18222 API paths and EN 18221 back-up replicationPending

  The EN 18222 REST paths (v1/dpps/…) are not implemented; the TracePass v1 API covers the same operations in its own shape, including a by-date version read. Replication of passports and their archive to a back-up provider (EN 18221, clauses 4.3 and 4.5) is not built either — who may act as a back-up provider waits on the ESPR service-provider delegated act.

• CIRPASS vocabulary alignmentPending

  Templates are designed to align with CIRPASS vocabulary recommendations; a formal field-by-field alignment document has not yet been published.

• 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). Required roles are set per category in the platform, drawn from the operator obligations in each law: batteries require manufacturer, recycler and producer-responsibility organisation, with importer, authorised representative and distributor optional (Battery Regulation 2023/1542 Art. 38 for manufacturers, Arts. 56–57 for extended producer responsibility and PROs); packaging and FMCG require manufacturer and PRO (PPWR 2025/40 Arts. 45 and 47); toys require manufacturer and importer (Toy Safety Directive Arts. 4 and 6). Requiring a recycler and a PRO is the platform's choice, not an EU-law requirement: producers may fulfil extended producer responsibility individually or through a PRO (Battery Regulation Art. 57(1), PPWR Art. 47(1)), though a Member State may make a PRO mandatory for batteries. A missing required role is flagged but never blocks publishing. 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 (43 paths, 53 operations across passports, products, exports, EPCIS). 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. The API covers the full DPP workflow — passports, products, exports, and EPCIS events; account management and billing are dashboard-only.

• GS1 EPCIS 2.0 — supply-chain event export, capture and queryIn place

  Full GS1 EPCIS 2.0 — export, capture and query — included on every plan, Free included. Any passport's supply-chain, service, and ownership events serialise as a standards-valid EPCIS 2.0 JSON-LD document, advertised on the GS1 Digital Link resolver as the gs1:traceability linkType, so an EPCIS-aware system that scans the QR discovers the event history without prior knowledge of the URL. Production steps that GS1's Core Business Vocabulary doesn't define (smelting, rolling, finishing) use TracePass-owned vocabulary URIs under tracepass.eu/voc/cbv/bizstep/ — the GS1-sanctioned industry-extension pattern — each resolving to its own published definition. Capture accepts events POSTed by suppliers and ERP systems, and the AI agent drafts events from datasheets for human review; query is served by an EPCIS 2.0 query interface we operate in the EU. Volume meter scales by tier (1,000 events/mo on Basic up to 10,000,000 on Pro, unlimited on Enterprise; Free gets 10 as an evaluation guardrail). A reproducible self-test ships at scripts/epcis-conformance-check.ts.

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 DPP Registry is live for operator enrolment, but it registers operators and product identifiers; it does not approve vendors. The legitimate signals are: GS1 (the identifier-allocation authority), CIRPASS / CIRPASS-2 (the EU-funded coordination action preparing the registry), and BatteryPass-Ready, the successor to the Battery Pass project (concluded March 2025), which maintains the battery-passport data model and a voluntary test environment.

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. Not yet applied.

• CIRPASS-2 Stakeholder Community — subscriberIn place

  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 (Grant Agreement 101158775, May 2024 → April 2027). The Stakeholder Community tier covers the newsletter, events and public consultations. TracePass joined on 2026-05-16. The CIRPASS-2 Memorandum of Understanding belongs to the Community of Practice application below, not to this tier.

• CIRPASS-2 Community of Practice (CoP) — applicantIn progress

  The Community of Practice is the active engagement tier of CIRPASS-2, reserved for DPP service providers and PLM/ERP/PIM/MES software vendors. CoP membership requires ~5-10 person-days/year, a signed MoU with the project coordinator (CEA), and contribution to DPP Stakeholder Exchange Forum activities. CoP registration is personal, so the MoU was signed by founder Malin Ivanov as an individual expert (with TracePass named as his organisation) on 2026-05-16 and submitted with the application. TracePass applied 2026-05-16 for CoP membership; subject to CIRPASS-2 evaluation procedure.

• CIRPASS-2 DPP Stakeholder Exchange Forum — circular-data.orgIn place

  circular-data.org is the CIRPASS-2 DPP Stakeholder Exchange Forum — the matchmaking and knowledge-exchange platform (hosted by Ekodenge on Clusterly) that connects DPP solution providers, manufacturers, and standards bodies across the EU. TracePass registered its organisation profile in May 2026 as an SME DPP-as-a-Service provider; the profile was reviewed, approved, and is publicly listed. This is a distinct registration from CIRPASS-2 Stakeholder Community and Community of Practice membership, which are evaluated separately.

• BatteryPass-Ready — successor to the Battery Pass project

  The Battery Pass project, a BMWK-funded German consortium, published content guidance and a reference data model for the EU Battery Passport (mandatory from 18 February 2027 under Regulation (EU) 2023/1542) and concluded in March 2025. Its successor, BatteryPass-Ready (led by Fraunhofer IPK with acatech, GEFEG and TU Berlin), maintains the battery-passport JSON schemas and runs a voluntary test environment; it is not an official EU conformance gate and issues no certificate. We map TracePass battery passports to the BatteryPass-Ready schemas and check them against its validator internally; customers cannot yet run that check from the dashboard. TracePass is not a BatteryPass-Ready Supporting Partner.

• EU DPP Registry: verified economic operatorIn place

  The EU DPP Registry — set up under Article 13 of ESPR (Regulation (EU) 2024/1781), with its rules in Implementing Regulation (EU) 2026/1778 — is live. TracePass LTD is enrolled and verified as an economic operator on the production registry. Registering a passport is not yet possible for any product group, batteries included: the Commission has not yet defined the semantic catalogue that submissions are checked against, and the registration API has no published specification. When registration opens, uploading the identifiers remains the duty of the economic operator placing the product on the market; we are tracking the specification and will add registration support when it is published. The registry holds identifiers, not passport data — the passport itself stays hosted by the operator.