Transfer Impact Assessment (TIA)
Required under Schrems II (CJEU C-311/18) for every transfer of personal data to a third country relying on Art. 46 GDPR safeguards. Conducted per the EDPB Recommendations 01/2020 six-step methodology, updated for the EDPB Recommendations 02/2020 European Essential Guarantees. One TIA per third-country sub-processor; multiple processors share the same destination-country analysis. v1 drafted 2026-05-15; T4 added 2026-09-04.
Counsel-review status
Developer-drafted v1. Counsel confirms the destination-country analyses (US Section 702 / EO 14086 / Cloud Act / FISA), validates the supplementary measures, and signs the per-transfer conclusion. ANSPDCP-specific overlay reviewed under F11.0.5.
In-scope transfers
| # | Sub-processor | Destination | Data categories | Frequency |
|---|---|---|---|---|
| T1 | Clerk | United States | Identity (email, name, phone, DOB, locale), authentication metadata, OAuth tokens | Continuous (every sign-in) |
| T2 | Cloudflare | Global edge — primarily EU, possibly other regions per routing | Request metadata (IP, headers, URL, TLS handshake), public-cacheable assets | Continuous (every request) |
| T3 | AWS (parent-access surface) | EU primary; US parent-corporation theoretical access via legal process | All platform data (host) | The data does not transfer to the US in runtime; the TIA addresses the residual risk of US-legal-process access to EU-stored data via Amazon's US parent |
| T4 | Daily.co | Media servers pinned to EU (geo = eu-central-1); control plane, account and support in the United States | Art. 9 health data — live audio/video of a rehabilitation consultation; in-call display name; opaque participant reference; WebRTC connection metadata | Per consultation |
Out of scope:
- Bunny.net (Slovenia / EU-only).
- Sentry (EU-only region selected and immutable).
- FGO (Romania).
- AWS for runtime data — runtime stays in
eu-central-1; only the parent-access scenario is TIA-relevant.
Methodology
The six EDPB steps applied to each transfer:
- Know your transfer. Map the data flow.
- Identify the transfer tool. SCCs (2021 Implementing Decision (EU) 2021/914), Module 2 (controller-to-processor) or Module 3 (processor-to-processor).
- Assess the law and practice of the destination country. Apply the EDPB European Essential Guarantees (EEG): clear, precise, accessible rules; necessity and proportionality; independent oversight; effective remedy.
- Identify supplementary measures. Contractual, organisational, technical.
- Adopt formal procedural steps. Document the SCCs, the supplementary measures, the assessment outcome.
- Re-evaluate at appropriate intervals. Annually or on material change of law or practice in the destination country.
T1 — Clerk (United States)
Step 1 — Know your transfer
| Element | Detail |
|---|---|
| Data exporter | {{LEGAL_ENTITY}} (Processor); transfer is processor-to-sub-processor |
| Data importer | Clerk, Inc. (US Delaware corporation) |
| Data subjects | Patients (and clinic staff post-launch) signing up to the platform |
| Categories | Email, name, phone (E.164), DOB (where collected), OAuth provider tokens, IP, user-agent, last-login |
| Special categories | None. Clerk does not receive health data, CNP, or clinical content |
| Purpose | Identity provider — authentication, session management, JWT issuance |
| Mechanism | API calls from API to api.clerk.com; outbound webhook from Clerk to API for user-lifecycle events |
| Frequency | Every sign-up, sign-in, profile update, OAuth flow |
| Volume | At launch: ~5,000 patient accounts → growth-tracking |
| Storage in third country | Clerk's primary stores are in US AWS regions |
Step 2 — Transfer tool
EU 2021 SCCs, Module 2 (controller-to-processor) — even though the exporter is itself a processor, the SCCs adopted by the Parties cover the controller-to-sub-processor flow under the General Authorisation regime in the tenant DPA §6. Clerk has executed SCCs as Importer.
Clerk's executed DPA: clerk.com/legal/dpa.
Step 3 — Destination-country law
The legal landscape in the United States affecting the transfer includes:
- Section 702 FISA — bulk surveillance authorities for non-US persons; can compel US-based electronic communication service providers to disclose communications.
- Executive Order 12333 — broader bulk-collection authorities; less directly applicable to a B2B SaaS provider but in scope for the EEG analysis.
- CLOUD Act (2018) — extraterritorial reach of US legal process to data held by US-controlled providers regardless of storage location.
- Executive Order 14086 (October 2022) — Biden-era reforms introducing necessity-and-proportionality principles and a Data Protection Review Court for EU complainants; foundation for the EU-US Data Privacy Framework (DPF).
- EU-US Data Privacy Framework adequacy decision (2023) — covers entities self-certified to the DPF; adequacy decision currently in force pending judicial challenge.
Clerk's DPF status: to be confirmed ({{CLERK_DPF_STATUS}}). If Clerk is DPF-certified, the transfer can rely on the DPF adequacy decision (an Art. 45 mechanism) and the SCCs become a fallback. If Clerk is not DPF-certified, the SCCs are the primary mechanism and this TIA's analysis remains load-bearing.
EDPB European Essential Guarantees applied:
| EEG | Assessment |
|---|---|
| Clear, precise, accessible rules | Partially. US surveillance authorities are publicly defined but interpretation is largely classified. EO 14086 improves transparency for EU subjects |
| Necessity and proportionality | EO 14086 introduces explicit proportionality language; prior to EO 14086 the legal position was less clear |
| Independent oversight | Strengthened by EO 14086's Data Protection Review Court for EU complainants; pre-2022 oversight (FISC) was assessed by the EDPB as insufficient |
| Effective remedy | EO 14086's DPRC provides a remedy mechanism for EU complainants for the first time; effectiveness under judicial review |
Step 4 — Supplementary measures
| Measure | Type | Effect |
|---|---|---|
| No special-category data sent to Clerk | Technical | Removes the highest-sensitivity attack surface. Health data, clinical records, CNP are never transmitted to Clerk |
| Pseudonymisation of platform-side identity | Technical | Platform-side records (patients, clinical data) reference Clerk's user ID; the Clerk record itself contains only the identity attributes the patient explicitly provides at sign-up |
| Minimum-necessary attribute collection | Organisational | Platform avoids sending Clerk any attribute beyond what authentication requires |
| Transparency to Data Subjects | Organisational | Privacy notice and sub-processor list disclose the transfer; Clerk's role + jurisdiction explained |
| Government-access transparency | Contractual + Organisational | Clerk publishes a transparency report; their DPA commits to challenge invalid orders and notify the controller where legally permitted |
| Access logging | Technical | Clerk logs administrative access; platform retains logs from the management API integration |
| Termination contingency | Organisational | If Clerk loses DPF status, fails an audit, or the DPF adequacy decision is invalidated, the platform has an Identity-Provider-swap contingency documented at {{IDP_SWAP_RUNBOOK}} (to be drafted in operations) |
Step 5 — Procedural steps adopted
- 2021 SCCs Module 2 executed via the Clerk DPA:
{{CLERK_DPA_DATE}} - This TIA documented and version-controlled
- Sub-processor inclusion in sub-processor list
- Privacy notice disclosure of US transfer in the Controller's published privacy notice
Step 6 — Re-evaluation triggers
- Annual review by the DPO
- On material change in US surveillance law or EU adequacy decision
- On invalidation of EU-US DPF (if applicable)
- On Clerk corporate change of control
- On material change in the data sent to Clerk
Conclusion (subject to counsel)
The transfer to Clerk is permissible under SCCs + supplementary measures, given the bounded data scope (no special-category data), the supplementary technical and organisational measures listed, and the EO 14086 framework. If the EU-US DPF adequacy decision remains in force and Clerk is DPF-certified, the transfer additionally benefits from adequacy.
The transfer remains the highest-impact international-transfer dependency at launch. The IdP-swap contingency is the documented mitigation against worst-case adequacy invalidation.
T2 — Cloudflare (global edge)
Step 1 — Know your transfer
| Element | Detail |
|---|---|
| Data exporter | {{LEGAL_ENTITY}} |
| Data importer | Cloudflare, Inc. (US) — operates global edge |
| Data subjects | Every visitor to the platform's public surfaces + every authenticated user whose request traverses the edge |
| Categories | Request metadata (IP, user-agent, URL, TLS metadata), public-cacheable assets, no authenticated request bodies cached |
| Special categories | None routinely. Request URLs do not encode special-category data. Authenticated request paths pass through without body inspection by edge cache |
| Purpose | DNS, CDN, WAF, DDoS protection, custom-hostname routing |
| Mechanism | TLS-terminating edge; re-establishes TLS to origin (ALB) |
| Frequency | Every request |
| Volume | High (every page load, every API call) |
| Storage in third country | Cloudflare edge is global; logs retained by Cloudflare at US HQ (subject to their published retention) |
Step 2 — Transfer tool
2021 SCCs, Module 2 (controller-to-processor) per Cloudflare's standard DPA: cloudflare.com/cloudflare-customer-dpa.
Step 3 — Destination-country law
Same US law analysis as T1.
Step 4 — Supplementary measures
| Measure | Type | Effect |
|---|---|---|
| No authenticated bodies cached | Technical | Patient and clinical data not in edge cache; only public, non-authenticated assets are cached |
| TLS termination + re-encryption | Technical | In-flight protection on both legs; edge node sees plaintext briefly for TLS termination and WAF inspection only |
| WAF rules block credential-bearing requests from being logged in plaintext | Technical | Authorisation headers, cookies, tokens stripped from any edge log capture |
| EU PoPs as default | Operational | Romanian traffic terminates at EU PoPs in practice; non-EU termination is not contractually guaranteed |
| Optional: Cloudflare Data Localization Suite | Technical / Contractual | Under evaluation. If adopted, contractually guarantees EU-only termination + EU-only logging at additional cost. Decision pending — see June launch plan WAF row |
| Government-access transparency | Contractual + Organisational | Cloudflare publishes a transparency report; warrant canary; notifies customers where legally permitted |
Step 5 — Procedural steps adopted
- 2021 SCCs executed via Cloudflare customer DPA at account creation
- TIA recorded
- Data Localization Suite decision pending — re-record if adopted
Step 6 — Re-evaluation triggers
Annual review + on material change to US law or Cloudflare's routing-region commitments.
Conclusion (subject to counsel)
The transfer to Cloudflare is permissible under SCCs + supplementary measures, given the bounded data scope (request metadata + public assets; no authenticated bodies cached) and the routing pattern that keeps Romanian traffic on EU PoPs in practice. Adopting the Data Localization Suite would strengthen the conclusion at additional cost; the decision is logged separately.
T3 — AWS (parent-access surface)
Step 1 — Know your transfer
| Element | Detail |
|---|---|
| Data exporter | {{LEGAL_ENTITY}} |
| Data importer | Amazon Web Services EMEA SARL (Luxembourg-domiciled EU entity); parent Amazon Web Services, Inc. (US) |
| Data subjects | All platform data subjects |
| Categories | All platform data (host) — including special-category health data, CNP (encrypted), audit log, clinical records |
| Special categories | Yes — health data; this is the highest-sensitivity transfer surface, though all data remains in the EU at runtime |
| Purpose | Hosting (RDS, ECS, S3, KMS, SES, ALB, CloudWatch) |
| Mechanism | Runtime processing in eu-central-1 (Frankfurt) |
| Frequency | Continuous |
| Volume | Entire platform |
| Storage in third country | None at runtime. The TIA addresses the theoretical US-legal-process access surface via AWS's US parent under the CLOUD Act |
Step 2 — Transfer tool
AWS EMEA SARL is an EU entity (Luxembourg). Contracting is with the EU entity. EU-to-EU data flow does not require Art. 46 mechanisms. The TIA exists nonetheless because of the CLOUD Act reach to the US parent.
For the CLOUD Act surface, AWS's standard DPA includes the 2021 SCCs as a contingency mechanism applicable to scenarios where US legal process is asserted: aws.amazon.com/service-terms + supplementary clauses in the AWS DPA.
Step 3 — Destination-country law
Same US law analysis as T1, with the AWS-specific consideration that the CLOUD Act has been narrowly applied to date and AWS has publicly committed to challenge invalid orders.
Step 4 — Supplementary measures
| Measure | Type | Effect |
|---|---|---|
| AWS BAA | Contractual | HIPAA framing but the closest analogue to "AWS as designated processor for special-category data." Accepted in AWS Artifact pre-launch |
| Column-level encryption with platform-controlled KMS keys | Technical | auth_secret (credentials, API keys, signing secrets) and pii_regulated (CNP) encrypted at column level with KMS keys whose policies prevent AWS administrative access to plaintext |
| Customer-managed KMS migration path | Technical | The Phase 1 posture is AWS-managed KMS keys; the migration path to customer-managed CMKs is documented at aws-infrastructure.md → Customer-managed KMS migration path. Trigger condition: F11.0.5 counsel recommendation or scale demands |
| Archive bucket lockdown | Technical | Public access fully blocked (ACLs, policies, and public-bucket restriction); server-side encryption under a dedicated KMS key; Object Lock in COMPLIANCE mode so no principal can delete inside the retention window. ⚠️ There is no bucket policy denying cross-account or cross-region copy; access is constrained by IAM rather than by a resource policy |
Database in eu-central-1 only | Operational | RDS and Aurora instances are region-pinned at provisioning |
| Single-region EU processing | Operational | All data stays in eu-central-1; nothing is replicated anywhere. ⚠️ Cross-region DR replication is not configured — if it is adopted it will be EU-to-EU, and this row is revisited then |
| CloudTrail organisation-level logging | Technical | All AWS API calls audit-logged; access to logs restricted; integrity verified |
| AWS transparency reports + commitment to challenge | Contractual + Organisational | AWS publishes transparency reports; commits to challenge invalid government orders |
Step 5 — Procedural steps adopted
- AWS DPA + SCCs accepted at account creation
- BAA accepted in AWS Artifact pre-launch
- KMS policies reviewed by DPO
- Region-pinning enforced via Terraform IaC
Step 6 — Re-evaluation triggers
- Annual DPO review
- On material change to US law (CLOUD Act amendments, FISA reform)
- On AWS corporate change affecting the EMEA SARL contracting structure
- On any AWS-reported CLOUD Act compulsory disclosure affecting EU data
- On migration to customer-managed CMKs (Phase 2) → TIA updated
Conclusion (subject to counsel)
The transfer-related risk for AWS is mitigated by the EU-only runtime processing combined with the contractual, technical, and organisational supplementary measures. The CLOUD Act surface is residual and addressed by transparency reporting, the BAA, the encryption posture for the most-sensitive columns, and (Phase 2) the customer-managed KMS migration path. The risk is comparable to other major hyperscalers; running on non-hyperscaler EU-only providers would be an alternative, but the operational and security trade-offs are documented in aws-infrastructure.md and were assessed as net-negative for the platform's launch posture.
T4 — Daily.co (United States)
This is the only transfer in this document that carries Art. 9 special-category data. It is assessed to a higher standard than T1–T3 for that reason.
Step 1 — Know your transfer
| Element | Detail |
|---|---|
| Data exporter | {{LEGAL_ENTITY}} (Processor); transfer is processor-to-sub-processor |
| Data importer | Daily, Co., 548 Market St., Suite 39113, San Francisco, CA 94104-5401, USA |
| Data subjects | Patients and clinicians taking part in a video consultation |
| Categories | Live audio and video of the consultation; in-call display name; opaque participant reference; room reference; token expiry; WebRTC connection metadata (IP, device, network quality) |
| Special categories | Yes — Art. 9. A rehabilitation consultation is the patient discussing and demonstrating a health condition. The media stream is health data in the clear at the point the media server relays it |
| Purpose | Real-time video consultation between patient and clinician (F5.5) |
| Mechanism | Server-side REST calls from the API to api.daily.co (room creation, meeting-token minting); browser WebRTC media to the pinned EU media server; signed webhooks from Daily to the API for room lifecycle |
| Frequency | Per consultation — not continuous |
| Volume | Low at present. Video consultations run for RestartiX-the-clinic only |
| Storage in third country | None intended. Media is relayed, not recorded. Room and token metadata live in the provider's control plane (US). Connection logs per the provider's retention |
Step 2 — Transfer tool
2021 SCCs, Module 3 (processor-to-sub-processor), in force.
No separate signature was required and none should be sought. Daily's Terms of Service §4 provides that "all data processing activities by the Services will be governed by the Data Processing Addendum ('DPA') incorporated by reference herein", and the DPA states that "by entering into the Agreement, Data Exporter is deemed to have signed these Standard Contractual Clauses incorporated herein, as of the Effective Date of the Agreement". Accepting the Terms at account creation therefore executed both the Art. 28 contract and the Art. 46 transfer tool.
DPA §6.2 selects the module from the parties' actual roles rather than fixing one: Module 2 where the customer is a controller, and Module 3 where the customer is itself a processor and Daily is processing on its behalf as a sub-processor. That is precisely our position — the clinic is the controller, the platform is its processor, Daily is the sub-processor — so the correct module applies automatically, without either party having to elect it.
What this does not settle is which legal entity holds the account that accepted those Terms, since the account is shared with the legacy system. See Step 5.
Step 3 — Destination-country law
Same US law analysis as T1 (FISA §702, EO 12333, EO 14086, CLOUD Act; EEG assessment at T1 Step 3), with two differences that cut in opposite directions:
- Aggravating: the data is Art. 9. A compelled disclosure would expose health data rather than identity data.
- Mitigating: there is nothing at rest to compel. §702 directives and CLOUD Act warrants reach stored communications and prospective interception. A relayed, unrecorded media stream leaves no store to produce, and prospective interception of a specific future consultation is a narrow and individually-targeted scenario rather than the bulk-access scenario the EEG analysis is built around.
Step 4 — Supplementary measures
| Measure | Type | Effect |
|---|---|---|
EU geo pinning, enforced by refusal | Technical | Media servers are pinned to eu-central-1. The adapter errors rather than defaults when geo is unset, so a misconfiguration fails closed instead of quietly relaying EU health data through a US media server |
| No recording | Technical | Rooms are created without recording and no code path enables it. There is no consultation media at rest anywhere — at the provider or with us. This is what makes the Step 3 mitigation real rather than rhetorical |
| Pseudonymous participants | Technical | The provider receives an opaque participant reference, never the patient identifier. Webhooks attribute back to a consultation on our side; the provider cannot resolve a participant to a person from what we send it |
| No clinical context | Technical | Room names are derived references. Nothing in the room, token, or webhook payload conveys the condition, the appointment, the offering, or the clinician's specialty |
| Private rooms, expiring per-participant tokens | Technical | privacy: private; every join requires a token minted by us, scoped to one participant and one room, with a mandatory expiry (the adapter refuses a token without one). eject_at_room_exp is true, so expiry ends a call in progress rather than only refusing new joins |
| E2E media encryption (DTLS-SRTP) | Technical | WebRTC media is encrypted in transit on every leg. The SFU relays and therefore sees plaintext media — insufficient on its own, which is why "nothing at rest" carries the weight here |
| Access window enforced by us, not the provider | Organisational | Join eligibility is decided at IssueJoin in our service, the only place a token is minted. The provider is not asked to make an authorisation decision |
Step 5 — Procedural steps adopted
| # | Step | Status |
|---|---|---|
| 1 | TIA recorded | ✅ this document |
| 2 | Technical measures implemented in code | ✅ services/api/internal/core/domain/video/daily.go |
| 3 | 2021 SCCs / DPA in force with Daily, Co. | ✅ executed by incorporation at account creation — Step 2 |
| 4 | Platform-owned provider account, separate from the legacy restartix-leo account | ⛔ NOT DONE. Two systems in one provider tenancy is an Art. 32 segregation problem, and it leaves the contracting entity on the account unconfirmed |
| 5 | Confirm which legal entity accepted the Terms on that account | ⚠️ Unverified. The same company stands behind both systems, so the likely answer is the right one — but "likely" is not a record, and this is the fact the Step 2 conclusion rests on |
| 6 | enable_recording sent explicitly rather than inherited from the account default | ⛔ NOT DONE — the control is correct in effect but is not asserted in our request |
| 7 | Sub-processor notice to controllers | ⚠️ owed before a third-party clinic is onboarded |
Step 6 — Re-evaluation triggers
Annual review, plus immediately on any of: recording being enabled for any purpose; the video_recording consent instrument being published; a change to the provider's media-region commitments; the provider being replaced by whereby or a self-hosted deployment (the schema supports both); or a material change to US surveillance law.
Conclusion (subject to counsel)
On the technical analysis the transfer is defensible, and more so than T1: the data is more sensitive, but the safeguards are stronger and — decisively — there is nothing at rest to disclose. Media is relayed through an EU-pinned server, never recorded, and the provider holds no means of connecting a participant to a person.
On the contractual analysis the transfer is permissible. The Art. 28 contract and the Art. 46 transfer tool are both in force, with the module that matches our processor-to-sub-processor position, and they took effect at account creation rather than requiring an act nobody performed.
What remains is one open fact rather than an open obligation: the account is shared with the legacy system, so the entity on the contract has not been confirmed and the two systems are not segregated. That is an Art. 32 point and a record-keeping point, not a missing safeguard, and moving to a platform-owned account resolves both at once. It should complete before a third-party clinic is onboarded.
Cross-transfer aggregate conclusion
The platform conducts four distinct international-transfer-related arrangements:
- T1 Clerk: real ongoing transfer of bounded identity data; permissible under SCCs + supplementary measures + (where applicable) DPF adequacy.
- T2 Cloudflare: transfer of request metadata + public assets; permissible under SCCs + supplementary measures; strengthenable via Data Localization Suite.
- T3 AWS: runtime data stays in EU; CLOUD Act parent-access surface mitigated by encryption, transparency, and the customer-managed KMS migration path.
- T4 Daily, Co.: Art. 9 media, relayed through an EU-pinned server and never recorded — the strongest technical posture in this document. SCCs Module 3 are in force by incorporation. The open point is that the provider account is shared with the legacy system, leaving the contracting entity unconfirmed and the two systems un-segregated.
None of the four carries a CJEU-actionable level of risk on the current EEG analysis. T4 deserves the closest reading despite that, because it is the only one carrying special-category data, and because the safeguard that does most of the work there is an engineering choice rather than a contractual one: nothing is recorded. If that ever changes, T4 is re-assessed from the start, not amended.
The aggregate posture is defensible and proportionate to the platform's scale. Counsel's binding review under F11.0.5 D1 is the gating sign-off, and has not yet been obtained.
Change log
| Date | Change |
|---|---|
| 2026-05-15 | Initial v1 — T1 Clerk, T2 Cloudflare, T3 AWS |
| 2026-09-04 | T4 Daily, Co. added — Art. 9 consultation media transferred to a US sub-processor, previously unrecorded here. Aggregate conclusion revised. |