--- title: Trust & security — what we run, where we run it description: "Procurement reference: EU data residency, sub-processor register with DPA links, security, liability, GS1 Digital Link / Schema.org / CIRPASS conformance." canonical: "https://www.tracepass.eu/trust" locale: en source: "https://www.tracepass.eu/trust" --- # Trust & security — what we run, where we run it > Procurement reference: EU data residency, sub-processor register with DPA links, security, liability, GS1 Digital Link / Schema.org / CIRPASS conformance. Procurement-grade reference for data residency, sub-processor disclosures, security posture, liability, and interoperability conformance. Items not yet in place are flagged so readers see what's done versus what's in flight — the buyer's guide cites this page as the single source of truth for both. ## Overview 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. ## Data residency 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 is self-hosted MongoDB on the same Hetzner Falkenstein server; 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-end: Hetzner CX22, Falkenstein, Germany - Marketing front-end: Vercel EU edge regions - Primary database: Self-hosted MongoDB 7, Hetzner Falkenstein, Germany - File storage: Cloudflare R2, EU regions ## Security posture 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 rest: File storage (Cloudflare R2) — AES-256. Application database — volume-level disk encryption on the database server is being rolled out. - Encryption in transit: TLS 1.3 - Authentication: JWT (HS256, 15 min) + refresh-token rotation (30 d, single-use, max 5 per user) - Role-based access control: owner > admin > editor > viewer; per-route enforcement - Rate limiting: Login (5/15min/IP), registration (5/min/IP), file upload (60/min/company), v1 API (per plan) - Database backups: Daily automated logical backup to an encrypted EU bucket (Cloudflare R2), 7-day retention, stored off the database server - Audit logs: Every passport edit recorded with timestamp, actor, and field-level diff; surfaced in the dashboard timeline - Security headers: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy - ISO 27001 certification: 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 report: 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 data residency + GDPR processor terms, which are documented above and in the DPA. ## Liability & insurance 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 cap: 12× monthly fees - Enterprise rider: 24× monthly fees, available on Enterprise contracts - E&O insurance: Quote in flight; cap will be published here once policy binds - [Master Services Agreement](/terms): 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. ## Interoperability conformance 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 conformance: 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-LD: 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 URLs: 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