DPA Annex 1 — Technical and Organisational Measures (TOMs)

This Annex describes the technical and organisational measures (TOMs) implemented by WORQABLE BV as Processor under §6 of the Data Processing Agreement and Article 32 GDPR. It is updated as the technical posture of the Service evolves; material changes are notified to Customers per §6.7 of the Algemene Voorwaarden.

Version: 1.0 — effective 15 May 2026.

1. Confidentiality

1.1 Encryption in transit

• All HTTP traffic to and from the Service uses TLS 1.3 at the public edge. Older TLS versions are disabled.
• Internal traffic between application and database within the Coolify managed network is TLS-encrypted.
• Outbound traffic to sub-processors (Anthropic, OpenAI, Mailjet, DeepL) uses TLS 1.3.

1.2 Encryption at rest

• All data files on production hosts are stored on LUKS full-disk-encrypted volumes managed by Hetzner.
• The Postgres database is hosted on the same encrypted volumes; no separate database-layer encryption is configured (LUKS is sufficient given the threat model — see §5 of /docs/sales/security-and-trust).
• BYOK API keys (Enterprise customers' Anthropic / OpenAI keys) are encrypted at rest with AES-256-GCM with a per-record IV. The encryption key is held in the AI_ENCRYPTION_KEY environment variable, accessible only to the application server.
• HMAC signing keys are currently held as plaintext in the org_signing_keys table; migration to AES-256-GCM is on the Wave 3 roadmap.
• Ed25519 signing keys are encrypted at rest with AES-256-GCM where provisioned.

1.3 Pseudonymisation

• IP addresses in qr_analytics are pseudonymised: the last octet of IPv4 / last 80 bits of IPv6 are zeroed before storage.
• Raw User-Agent strings are not stored — only parsed categorical fields (browser family, device type).
• Track & Trace participant PINs are hashed with SHA-256 before storage; only the hash is verified on scan.

1.4 Access control

• Multi-tenant isolation: Postgres Row-Level Security policies on every multi-tenant table; enforced for both anonymous and authenticated requests. Last full RLS audit: 25 April 2026.
• Authentication: Supabase Auth with HTTP-only, SameSite=Lax cookies. JWT signed by per-instance secret.
• Service-role JWT: held only on the server, never sent to clients.
• API keys: hashed (SHA-256) before storage; the plaintext is shown only at creation.
• Webhook signatures: HMAC-SHA256 with timing-safe comparison (Stripe-format).
• Role-based access on the operator side: separate roles for engineering, support, and admin; least-privilege defaults.
• Multi-factor authentication: in roadmap; not yet shipped on operator accounts.

2. Integrity

2.1 Append-only audit log

• The audit_logs table is protected by BEFORE UPDATE, BEFORE DELETE, and BEFORE TRUNCATE triggers that raise an exception on any modification or removal attempt.
• Daily Merkle tree computation over the day's audit-log rows; the root is anchored into the Bitcoin blockchain via OpenTimestamps, providing an independent tamper-evidence proof.
• The verifier endpoint /api/v1/audit/verify is publicly accessible (Merkle proofs are public artefacts).
• Foreign keys from related tables to audit_logs.user_id use ON DELETE NO ACTION to preserve audit integrity on user deletion (see Privacy Policy §11 for the GDPR Art. 17(3)(b) basis).

2.2 Webhook idempotency

• Outbound webhooks include an idempotency_key (ULID); receivers can deduplicate.
• Inbound webhooks (e.g., from WQ SaaS billing) are deduplicated via the billing_webhook_log table with a UNIQUE constraint on correlation_id.

2.3 Anti-counterfeiting

• Per-workspace HMAC-SHA256 signing keys for product short URLs and GS1 Digital Link URIs.
• Per-workspace Ed25519 keys (where provisioned) with a published JWKS endpoint.
• The /api/v1/qr/sign endpoint validates that the URI is a GS1 Digital Link path (/01/<gtin>/...) before signing — protects against arbitrary URL forging.

3. Availability and resilience

3.1 Hosting

• Hetzner Online GmbH dedicated servers in Falkenstein, Germany.
• Coolify-managed Docker stacks (production: cluster y7flyx; demo: 8kpff4).

3.2 Backups

• Daily Postgres dumps to S3-compatible backup target (separate region within Germany).
• 30-day rolling retention on system-wide backups.
• Per-workspace export available via Settings → Backups (Customer-controlled). Plan-dependent storage quotas (100 MB to 20 GB).

3.3 SLA

• 99.5% monthly uptime target (Standard tier) / 99.9% (Enterprise tier). See SLA for the details.
• p50 < 200 ms / p95 < 500 ms / p99 < 2,000 ms response-time targets on GET endpoints.

3.4 Status page and incident framework

• Public status page at status.qrabl.eu.
• Severity tiers SEV1 (1h ack / 4h resolve), SEV2 (2h ack / 24h resolve), SEV3 (next business day).
• Internal Breach Response Playbook at /docs/compliance/breach-response-playbook.

4. Resilience and restoration

• Backup restore tested on a cadence documented in the Vendor Review SOP and the internal compliance calendar.
• Disaster recovery: documented hot-standby procedure on the Hetzner cluster (RPO ≤ 24h, RTO ≤ 4h).

5. Vendor management

• Sub-processors are vetted under the Vendor Review SOP before onboarding. The SOP requires: business justification, data-flow analysis, DPA execution, security questionnaire, risk rating, DPO sign-off.
• Sub-processor list maintained at /legal/subprocessors with a 30-day prior-notice obligation for additions.
• Sub-processor flow-down clauses are imposed by written contract.

6. Personnel

• All persons authorised to process Personal Data are bound by a contractual confidentiality obligation.
• AI literacy memo maintained at /docs/compliance/ai-literacy-memo and reviewed annually.
• Onboarding checklist includes data-protection awareness.

7. Application-layer controls

• Rate limiting: per-IP and per-token, backed by the Postgres rate_limits table (survives serverless cold-starts).
• Bot mitigation: ALTCHA proof-of-work on all public forms (waitlist, demo lead, label-access OTP request, engagement reviews).
• CSP: strict Content-Security-Policy headers; frame-ancestors 'self' for label preview iframes.
• CSRF: SameSite cookies + JSON Content-Type requirement.
• Soft deletes: filtered in all queries to prevent accidental disclosure of deleted records.
• Kill switches: server-side feature flags (e.g., isKilled('BILLING_WEBHOOK')) for fast disable of compromised endpoints without redeploy.

8. GDPR-specific controls

• In-product Data Subject Right tooling (Settings → Privacy & Data → Export My Data, Schedule Deletion, Immediate Deletion).
• Consent log (consent_log table) recording every grant and revocation with timestamp and IP.
• Double opt-in for marketing email (via Mailjet 48-hour token).
• Mailjet contact removal automated in the account-deletion cascade.
• Append-only audit-log retention as a GDPR Art. 17(3)(b) lawful basis (see Privacy Policy §11).

9. Auditability

• Full source code under version control with PR-based review.
• Internal audit cadence: quarterly substrate review, semi-annual RoPA + retention review, annual DPIA refresh, annual tabletop breach exercise.
• External audits: third-party penetration test scheduled for Q3 2026; ISO 27001 / SOC 2 not held (roadmap; bridge via questionnaire on enterprise request).

10. Special categories of personal data

QRabl is not designed to process special categories of Personal Data (Art. 9 GDPR). The Customer must notify the Processor under §3.2 AV before uploading special-category data; additional measures are applied case-by-case.

11. Children

QRabl is offered to businesses only and is not directed at children. End-consumer scan analytics are anonymised and do not include identifiers that would allow children to be identified.

12. Updates to this Annex

Material changes to this Annex are notified to Customers under §6.7 AV. The current version of this Annex prevails over previous versions.

---

For technical or compliance questions: privacy@qrabl.eu.