Transfer Impact Assessment — Third-Country Transfers
1. Purpose and relationship to existing documents
docs/compliance/dsgvo-data-flow.md §6 lists third-country transfers at a high level (Resend, APNs, FCM, Expo, Stripe) with a one-line mechanism reference per vendor. This document formalizes that into a per-transfer assessment, pulling the current, verified sub-processor list from register/facts.md rather than §6's (partly stale) vendor names — see the correction note in §5.
This is a real gap vs. `dsgvo-data-flow.md`, not just a formatting exercise: the push-notification vendors (Apple APNs, Google FCM, Expo Push API) are real, live third-country transfer surfaces per facts.md's sub-processor table, and none of them are individually assessed in §6 today — they're mentioned in §1's processor table but §6's transfer-mechanism prose only names Resend explicitly.
2. Per-transfer assessment
| Vendor | Purpose | Region | Third-country transfer? | Mechanism | Verification status |
|---|---|---|---|---|---|
| AWS SES | Transactional email — replaced Resend, confirmed via apps/web/lib/email/ses.ts | eu-central-1 (Frankfurt, EU) | No — processing region is EU | n/a | See §3 for the CLOUD Act nuance worth noting even where no Art. 44 transfer occurs |
| Apple Push Notification service (APNs) | iOS push routing | US | Yes | SCC + EU-US Data Privacy Framework (if Apple is DPF-certified for this service) | Open — verify Apple's current DPF certification scope covers APNs specifically, not just Apple's general listing |
| Google Firebase / FCM | Android push routing | US/EU (Google's own regional routing is not fully controllable by Stratify) | Yes, for the US-routed portion | SCC + DPF (if Google Firebase is in scope of Google's DPF certification) | Open — verify Firebase Cloud Messaging is within Google's certified DPF scope, and clarify actual data-residency behavior of the US/EU split |
| Expo Push API | Push-token routing intermediary between the app and APNs/FCM | US | Yes | SCC (Expo's DPF status not established) | Open — Expo's DPF certification status is not confirmed; do not assume DPF coverage without checking the DPF list directly |
| Stripe Payments Europe Ltd | Subscription payments | Ireland (EU) | No, for Stripe Payments Europe Ltd itself | n/a | Stripe's own sub-processors (US-based) transfer under Stripe's SCCs — Stratify has no direct card/IBAN access (dsgvo-data-flow.md §2) so this is a downstream transfer in Stripe's chain, not a direct Stratify transfer |
Vercel AI Gateway → Anthropic (claude-sonnet-4) | German signal-drafting assist | Not confirmed (facts.md sub-processor table) | Unknown pending verification | Unknown pending verification | Open — this is a distinct service from Vercel hosting (which is deactivated post-Hetzner-cutover); confirm whether it is still in active use, and if so, the Gateway's and Anthropic's processing region(s) and applicable transfer mechanism |
| PostHog | Analytics | eu.i.posthog.com (EU) | No | n/a | Already covered adequately in dsgvo-data-flow.md §6 |
| Sentry | Error telemetry, server-side only | EU | No | n/a | Already covered adequately in dsgvo-data-flow.md §6 |
3. AWS SES — correcting an assumption
dsgvo-data-flow.md §1 still lists Resend (EU + US email routing) as the transactional-email processor. facts.md confirms this is stale: AWS SES eu-central-1 replaced Resend (apps/web/lib/email/ses.ts:1-24, no resend package in apps/web/package.json). Processing region for AWS SES eu-central-1 is Frankfurt, Germany — this is not a third-country transfer under Art. 44 ff., correcting the implicit assumption carried over from Resend's EU+US routing description.
One nuance worth stating rather than glossing over: AWS as a corporate entity is US-headquartered, and under the US CLOUD Act, US law enforcement can in principle compel data disclosure from a US-headquartered provider regardless of where the data is physically stored. This is a standing tension discussed generally in EDPB/Schrems-II-adjacent guidance for any US-parented cloud vendor, not specific to AWS SES's transfer-mechanism status — the processing itself is EU-located and does not trigger Art. 44's transfer rules on its own. Flagging this for awareness, not re-scoring AWS SES as a third-country transfer.
4. Mechanism verification — what "SCC + DPF" actually requires per vendor
Do not assume DPF coverage blindly. The EU-US Data Privacy Framework only covers a US recipient if that specific entity has self-certified for the specific service in question, listed at the DPF list maintained by the US Department of Commerce. "The vendor is a well-known US company" is not sufficient evidence of DPF coverage for a given data flow. For each of the three open items in §2 (Apple APNs, Google FCM, Expo Push API), the concrete verification task is:
- Check the DPF list (dataprivacyframework.gov) for the exact legal entity operating the service.
- Confirm the certification scope includes the specific service/data category in question (a
company can be DPF-certified for some business lines and not others).
- If DPF coverage is confirmed, SCCs remain the fallback/supplementary mechanism per current EDPB
guidance on layered safeguards; if DPF coverage is not confirmed, SCCs (with a documented Transfer Impact Assessment addressing government-access risk per Schrems II) are the sole mechanism, and that TIA needs to be vendor-specific, not this table's one-line placeholder.
This document does not close those three verification items — it flags them as open so they don't silently get assumed away.
5. Correction needed in dsgvo-data-flow.md §6
Two concrete edits are needed the next time Antonios revises the operational document (tracked generally as a GOV-13 nonconformity candidate per facts.md's "Open items" section):
- Replace "Resend" with "AWS SES (
eu-central-1, EU — not a third-country transfer)" in the
processor table (§1) and transfer section (§6).
- Add explicit per-vendor lines for Apple APNs, Google FCM, and Expo Push API in §6 — today they
appear only in the §1 processor table, not assessed individually in the transfer section.
6. Review
Reviewed quarterly, aligned with the DPA review cadence already stated in dsgvo-data-flow.md §10, and immediately whenever a new third-country vendor is added or the Vercel AI Gateway → Anthropic open item in §2 is resolved.