Subprocessor Documentation
Directory of external service providers and processor governance
1. Legal objective and governance
This page operationalizes the obligation for transparent processor management under Art. 28 GDPR. It provides an internally defensible register for purpose limitation, data minimization, security obligations, and transfer governance.
It is published for transparency and does not supersede binding contract documents (in particular Terms (AGB), Seller Terms, Verification Policy, and Refund & Dispute Policy).
All statements are based on the current deployment configuration (as of February 16, 2026) and are subject to change control. Statements about external providers are based on their published documentation and contractual agreements. Subject to change.
2. Active processor classes (as of 2026-02-16)
The following processor classes are integrated in the current architecture. Classification is derived from deployment configuration and infrastructure-as-code definitions.
- Google Cloud / Firebase (Firestore, Authentication, Cloud Functions, Cloud Storage, Cloud KMS, Secret Manager, Cloud Logging, Cloud Monitoring): Core platform for user profiles, authentication, server-side logic, data storage, key management, and operational logging. Primary region: europe-west3 (Frankfurt). Secret Manager replication: europe-west4 (Netherlands). Data categories: identity data, profile data, deletion workflow state, operational logs
- Stripe: Payment and accounting processing. Stripe Connect account linkage, billing subcollections. Data categories: account linkage IDs, payment metadata. Third-country transfer possible (depending on Stripe configuration). Statutory retention carve-outs for accounting records
- Mailchimp (The Rocket Science Group LLC): Newsletter processing (opt-in, opt-out, delivery status). Data categories: email address, subscription metadata. Server location: configuration-dependent. Third-country transfer possible (US-based service). Deletion: subscriber removal via MD5+email hash in the erasure workflow
- Typesense (self-hosted on GCE): Search index for marketplace listings. Data categories: listing document data attributable to the user. Region: europe-west3 (self-hosted on Shielded VM with TLS via Caddy). Deletion: removal of user-owned listing documents in the erasure workflow
- Bugsnag (SmartBear Software): Monitoring and error telemetry. Data categories: error stack data, session metadata, potentially user-correlating context data. Third-country transfer possible. Open validation item (Privacy): Confirm data categories and transfer scope; consider restrictions.
- Amazon Web Services / SES: Transactional email delivery (account deletion OTP). Region: eu-central-1 (configured). Data categories: email address, OTP code. Short-lived processing; no persistent storage intended
- Vercel Inc.: Frontend hosting (Next.js). Serverless region: fra1 (Frankfurt). Data categories: edge request metadata, function execution logs. Client-side analytics (Vercel Analytics integrated). US-based company; EU serverless region configured. Open validation item (Privacy): Confirm scope of Vercel-side data processing and third-country transfer.
- Google Tag Manager: Client-side tag management. Data categories: browser event data per tag configuration. Open validation item (Privacy): Document deployed tags and their data categories.
3. Mandatory fields per register record
Each processor must be documented with the following mandatory fields in an internal register. The fields are designed to support an evidence review under Art. 28 GDPR.
- Vendor/service identity and functional scope within the platform
- Processing purpose and affected data categories
- Legal basis context for the processing
- Processing region(s) and transfer context (EU/EEA, third country, adequacy decision)
- SCC/TIA reference where applicable (module, version, assessment date)
- DPA status (signed/pending/not applicable) with contract date
- TOM status (documented/pending) with last review date
- Responsible team/role (owner), last review date, next planned review
- Evidence reference: pointer to specific storage location in the internal contract and assessment archive
4. Change control obligations
Changes to processors are treated as controlled events. No change may enter production without prior assessment and approval.
- Onboarding a new processor: Complete evidence package required before production use
- Change in region, purpose, data categories, or subprocessor chain: Mandatory reassessment and register record update
- Privacy policy, internal documentation, support messaging, and this Legal page are updated in release sync
- Incomplete evidence blocks production rollout and triggers compliance escalation
- Offboarding a processor: Document removal date, confirm data deletion/return, archive register record
5. Deletion and retention obligations per processor class
The deletion behavior for each processor must be explicitly defined. The following overview is based on the logic implemented in the erasure workflow.
- Google Cloud / Firebase: Primary identity data is directly deleted/anonymized in the erasure job (profile fields, auth identity, storage objects). Backups: no single-record deletion; removal via backup rotation (14 weeks configured). Cloud Logging: retention per log sink setting
- Stripe: Account linkage is anonymized; metadata is reduced to the minimum. Legally required accounting records may be retained with a pseudonymized subject key
- Mailchimp: Subscriber removal via API call (MD5 hash of email). Campaign logs are subject to provider-side retention
- Typesense: All user-owned listing documents are removed from the search index. Snapshot retention: 14 days (configured)
- Bugsnag: No direct per-user deletion implemented. Data minimization and provider-side retention/rotation. Open validation item (Privacy): Confirm deletion mechanism or data restriction.
- AWS SES / Vercel / GTM: Short-lived or client-side processing; no persistent user-specific storage intended. Provider-side retention settings apply
6. Customer transparency and update policy
This page serves as the primary information channel for the current processor list. Material changes (new processors, region changes, purpose changes) are reflected here.
Open validation item (Product): Define an additional notification mechanism (e.g., email notification for material processor changes, changelog feed).
The processor information presented here reflects the technical state of the deployment configuration and does not replace the legally binding agreements between the parties; transfer framework details are set out in DPA / SCC / TIA.
