DPA / SCC / TIA
Processor agreements and international data transfers
1. Legal framework and purpose
This page describes the minimum contractual and organizational standards for data processing agreements and international data transfers in the context of the prokodo Marketplace platform. It constitutes technical compliance documentation and does not replace legal counsel.
It is published for transparency and does not supersede binding contract documents (in particular Terms (AGB), Seller Terms, Verification Policy, and Refund & Dispute Policy).
Legal reference points: Art. 5 GDPR (principles), Art. 6 (lawful bases), Art. 28 (processors), Art. 32 (security of processing), and Art. 44 et seq. GDPR (transfers to third countries).
These requirements apply to all teams involved in the processing of personal data, including Engineering, Platform, Security, Product, Support, Legal, and Compliance.
All statements reflect the state as of February 16, 2026 and are subject to change control.
2. Definitions
The following definitions apply throughout this document to ensure clear and consistent interpretation:
- Processor: A natural or legal person that processes personal data on behalf of the controller (Art. 4(8) GDPR)
- Transfer: Any disclosure of personal data to a recipient in a third country or to an international organization (Art. 44 et seq. GDPR)
- Evidence package: The complete set of DPA, SCC, TIA, TOM documentation, and internal approval records for a processor
- Adequacy: An adequacy decision by the European Commission under Art. 45 GDPR
- Supplementary measures: Technical, organizational, or contractual measures to achieve an essentially equivalent level of protection for third-country transfers
- Open validation item (Legal): The role of prokodo as controller or processor must be determined and documented for each processing purpose; until formal assignment this page remains a technical draft.
3. Mandatory documents per processor
Before any processor is used in production, the following evidence package must be complete and internally approved. Production use without a complete evidence package is not permitted.
- Signed DPA (Data Processing Agreement) specifying subject matter, duration, nature and purpose of processing, and categories of data subjects and data in accordance with Art. 28(3) GDPR
- Applicable SCC (Standard Contractual Clauses) module in the current version, where transfers are made to recipients in third countries without an adequacy decision
- TIA (Transfer Impact Assessment) documenting the legal environment of the recipient country, government access scenarios, residual risk assessment, and supplementary safeguards
- TOM documentation (Technical and Organizational Measures): access controls, encryption, logging, incident management, deletion controls — to the extent demonstrably implemented
- Named owner (team/role), review interval, and evidence repository location in the central register
- Evidence reference: pointer to the specific storage location in the internal contract and assessment archive
4. SCC/TIA review standard (continuous review)
SCC and TIA are not one-off assessments but continuous control processes. The effectiveness of supplementary measures must be validated regularly.
- Minimum annual reassessment, plus event-driven reassessment on vendor, region, legal framework, or purpose changes
- Documentation requirements: transfer purpose, categories of data transferred, recipient type, safeguards applied
- Deviations must be tracked as compliance risks with: risk severity, owner, due date, and remediation plan
- No new or changed integration may enter production without documented approval
- Withdrawal or modification of an adequacy decision: immediate reassessment of affected transfers
5. Supplementary measures
Where a transfer is made to a third country without an adequacy decision, supplementary technical and organizational measures must be documented. The following statements are based on the current infrastructure configuration:
- Encryption at rest: Google-managed encryption at rest is active by default for Firestore and Cloud Storage. Terraform state is encrypted with Cloud KMS (europe-west3). Open validation item (Security): Evaluate and document CMEK/CSEK configuration for databases and persistent disks.
- Transport encryption: TLS is configured for all external connections (Typesense via Caddy reverse proxy, HTTPS-only; Vercel edge; Firebase APIs). Open validation item (Security): Document minimum TLS version and cipher suites.
- Access controls: Firestore and Storage rules enforce default-deny. Admin operations are restricted to server-side Cloud Functions (Admin SDK). SSH access to VMs is limited to IAP tunneling. OS Login is enabled. Shielded VMs with vTPM and integrity monitoring
- Key management: Sensitive credentials are stored in GCP Secret Manager (replication: europe-west4). Registry auth tokens are encrypted with AES-256. Open validation item (Security): Confirm key rotation policy.
- Network security: Custom VPC with private subnets and NAT gateway. VPC flow logs are enabled (0.5 sampling rate). No public IP for compute workers
- Logging: Admin read operations are logged in a dedicated audit collection (fields captured: actor, timestamp, action, purpose). Erasure audit events are logged separately with automatic secret sanitization
6. Relation to account erasure and retention
The account erasure model distinguishes two legally relevant statuses:
- erased_core: Core identifiers in the primary user profile and auth system are removed/anonymized. External connectors (Stripe, Mailchimp, Typesense, Storage) may still be pending
- erased_complete: All six configured erasure targets (Firestore core data, auth identity, Typesense index, storage objects, Stripe linkage, newsletter subscription) are terminal (succeeded or skipped/NOT_APPLICABLE). Evidence is documented in the erasure job record
- Retention periods: Erasure jobs 90 days, audit events 180 days, dead letters 180 days, tombstones 365 days — each TTL-enforced in Firestore (configured via Terraform resources)
- Backups and log streams do not support single-record deletion. Removal occurs through configured retention windows (Firestore backups: 14 weeks; Cloud Logging: per sink setting; error telemetry: per provider setting)
- Where statutory retention obligations apply, only the legally required minimum data may remain; the legal basis and retention period must be documented
7. Accountability and approvals (three-lines-of-defense)
Operational responsibility follows a three-lines-of-defense model designed to maintain an internal check-and-challenge structure.
- 1st line (Engineering/Platform): Technical implementation, evidence creation and maintenance, ongoing operations
- 2nd line (Security/Privacy/Compliance): Control challenge, risk acceptance or restriction, approval or rejection
- 3rd line (Audit/Management review): Periodic effectiveness review, independent sample testing
- Approval of new or changed transfers requires a complete evidence package
- Rollout-stop condition: Missing or incomplete documentation blocks production deployment
8. Transparency and customer information
Information about data processing agreements and deployed subprocessors is published on this Legal & Compliance page; the technical vendor inventory is available in the Subprocessors page.
Changes to the processor list or material changes to transfer contexts are updated on this page. Open validation item (Product): Define a customer notification mechanism for material changes (e.g., email notification, changelog feed).
The list of technically active processor classes is available on the Subprocessors page.
