EU Standard Contractual Clauses (SCCs) & EU Data Residency

A. What Standard Contractual Clauses (SCCs) Are — In Plain Language

When personal data about people in the European Union or European Economic Area (EEA) is sent to be handled by a company outside the EEA — for example, software hosted in the United States — EU law (the GDPR) requires a recognized legal safeguard to make that transfer lawful. Standard Contractual Clauses (SCCs) are the most widely used safeguard.

In short:

• What they are: A set of pre-written, standardized contract terms that the European Commission has officially approved (under Implementing Decision (EU) 2021/914, adopted 4 June 2021). They are sometimes called the "EU SCCs" or the "new SCCs."
• What they do: When both parties sign up to them, they create a binding promise that the personal data will be protected to an EU-equivalent standard even though it physically lives outside the EEA. They give the people whose data it is ("data subjects") enforceable rights and a route to remedies.
• Why they matter here: ScrambleSync runs on infrastructure located in the United States (Supabase / AWS in the us-west-1 region for the database and authentication). For any organizer (customer) covered by the GDPR, the SCCs are the legal bridge that makes it lawful to use ScrambleSync with EU/EEA personal data.
• The "Modules": The 2021 SCCs come in four flavors ("Modules") depending on the relationship between the parties. Module Two covers a Controller-to-Processor relationship — which is exactly the ScrambleSync arrangement: the organizer decides why and how the data is used (controller), and ScrambleSync processes it on the organizer's instructions (processor).

The SCCs work by attaching Annexes that fill in the specific facts: who the parties are, what data is transferred and why, which regulator oversees it, what security measures protect it, and which sub-processors are involved. Those Annexes are populated below.

B. SCC Incorporation Into the ScrambleSync DPA

For Customers subject to the GDPR, the EU Standard Contractual Clauses set out in the Annex to European Commission Implementing Decision (EU) 2021/914 of 4 June 2021, MODULE TWO (Controller-to-Processor), are hereby incorporated by reference into the ScrambleSync Data Processing Agreement ("DPA") and form an integral part of it. The Customer (acting as data exporter and controller) and ScrambleSync (acting as data importer and processor) agree to be bound by those Clauses.

Where the SCCs require the parties to make a selection, the following applies:

• Optional Clause 7 (Docking clause): Included — additional entities may accede to the Clauses.
• Clause 9 (Use of sub-processors): Option 2 — General written authorisation. ScrambleSync may engage the sub-processors listed in Annex III and will inform the Customer of any intended additions or replacements with at least 30 days' prior notice, giving the Customer the opportunity to object.
• Clause 11 (Redress): The optional independent dispute-resolution body language is not elected; data subjects may lodge complaints with a supervisory authority and pursue judicial remedy as provided in the Clauses.
• Clause 17 (Governing law): The Clauses are governed by the law of an EU Member State that allows third-party beneficiary rights — the parties select the law of the Republic of Ireland, unless the DPA's order form specifies a different qualifying Member State law.
• Clause 18 (Choice of forum and jurisdiction): Disputes arising from the Clauses will be resolved before the courts of Ireland, consistent with Clause 17, unless otherwise specified in the DPA.

In the event of any conflict between the SCCs and the rest of the DPA, the SCCs prevail to the extent of the conflict, in line with Clause 5 of the SCCs.

The Annexes required by the SCCs are populated in the sections below (Annex I.A Parties, Annex I.B Description of Transfer, Annex I.C Competent Supervisory Authority, Annex II Technical and Organisational Measures, and Annex III Sub-processors).

Annex I.A — List of Parties

Data Exporter (Controller)

• Name: The Customer (the tournament organizer / organization) that entered into the DPA. Full legal name, address, and contact point are as set out in the DPA order form or the Customer's account record.
• Role: Controller — determines the purposes and means of processing the personal data of its registrants, players, sponsors, and staff.
• Activities relevant to the transfer: Operating golf scramble tournaments using the ScrambleSync service, including registration, team and roster management, scoring, sponsor management, messaging, and payments.
• Signature and date: As recorded on acceptance of the DPA.

Data Importer (Processor)

• Name: Coyote Valley Technology Solutions, operator of the ScrambleSync service.
• Contact point: The privacy/data-protection contact published in the ScrambleSync DPA and privacy notice.
• Role: Processor — processes personal data solely on the documented instructions of the Customer to provide the ScrambleSync service.
• Activities relevant to the transfer: Hosting and operating the ScrambleSync platform, storing and processing tournament and participant data, sending transactional email on the Customer's behalf, processing payment metadata, and maintaining security, audit, and observability functions.
• Signature and date: As recorded on acceptance of the DPA.

Annex I.B — Description of Transfer

Categories of data subjects whose personal data is transferred:

• Tournament organizers, administrators, and staff with organizer invitations
• Tournament registrants, participants, golfers, and team members (including team captains)
• Tournament sponsors and advertisers
• Persons whose data appears in security, audit, and usage logs (any user of the service)

Categories of personal data transferred (drawn from the ScrambleSync data inventory):

• Organizer account data: full name, email address, authentication credentials and password hashes, MFA/passkey (TOTP/WebAuthn) credentials, organization name, session tokens
• Registrant information: name, email address, team name, phone number (if collected), imported rosters/player names
• Player/golfer data: player names, team assignments, hole-by-hole scores, handicaps (if tracked), player type (e.g., captain vs. member), cart assignments
• Payment transaction metadata: registration amount, payment status, Stripe session ID, payment intent ID, currency, item/product descriptions and prices (card data — PAN/CVV — is NOT transferred to or stored by ScrambleSync; it is handled entirely by Stripe)
• Sponsor/advertiser data: company name, logo URL, advertisement text and link URLs, sponsor access codes
• Tournament and event data: tournament/course names, configuration, rules, side-game settings, logos
• Communications: message text, direction, type, read status, team/tournament associations
• Integrity and compliance flags: flag type and severity, observed hole, reviewer notes, plus IP addresses and user agents captured in attestations
• Audit and security logs: actor email/ID, action type, tournament/target IDs, IP address, request ID, timestamp, anonymized PII counts
• Usage and performance telemetry: web vitals, page URLs, latency/metric samples, request IDs, pseudonymized user IDs
• Technical and security identifiers: IP addresses, user agents, request IDs, session tokens, admin session cookies, WebAuthn attestations

Sensitive data: ScrambleSync does not require or intend to process special-category data under GDPR Article 9. Organizers are instructed not to enter such data into free-text fields.

Frequency of transfer: Continuous, for the duration of the service (data is transmitted and processed on an ongoing basis as the Customer and its participants use the platform).

Nature of the processing: Collection, storage, organization, structuring, hosting, retrieval, transmission (including transactional email), pseudonymization/anonymization (erasure), logging, and deletion — all carried out by automated electronic means.

Purpose of the transfer and further processing: Solely to provide the ScrambleSync tournament service on the Customer's documented instructions — running registration, team generation, scoring, sponsor and messaging features, payment processing metadata, and the security/audit/observability functions necessary to operate the service securely. ScrambleSync does not sell the data and does not use it for advertising, profiling, or any independent purpose.

Retention period: As set out in the DPA retention schedule. Summary: registrant personal data is retained for the duration of the tournament plus 90 days (organizer-controlled, with erasure available at any time via the in-app erasure endpoint); audit events are immutable; web vitals and command-metric samples are auto-pruned after 30 days; application logs are retained ~30 days (DigitalOcean) / ~90 days (Sentry); organizer account data persists for the account lifecycle. Sub-processors retain data per their own DPAs.

Transfers to (sub-)processors: See Annex III. The subject matter, nature, and duration of sub-processor transfers match those described above.

Annex I.C — Competent Supervisory Authority

The competent supervisory authority is identified in accordance with Clause 13 of the SCCs and the European Data Protection Board guidance:

• Where the Customer (data exporter) is established in an EU/EEA Member State, the competent supervisory authority is the supervisory authority of that Member State (for example, the Irish Data Protection Commission, the French CNIL, the German state DPA, etc.), as identified in the DPA order form.
• Where the Customer is not established in the EEA but has appointed an EU representative under GDPR Article 27, the competent authority is the supervisory authority of the Member State in which that representative is established.
• Where the Customer is not established in the EEA and has no Article 27 representative, but the processing relates to data subjects in a single Member State, the competent authority is the supervisory authority of that Member State.
• Default selection (where the parties do not specify otherwise in the DPA): the Irish Data Protection Commission (DPC), 21 Fitzwilliam Square South, Dublin 2, D02 RD28, Ireland.

The specific competent supervisory authority for a given Customer should be confirmed in the DPA order form.

Annex II — Technical and Organisational Measures

The data importer applies the following technical and organisational security measures (TOMs). These reference controls verified in the ScrambleSync codebase; they are accurate as implemented and are not aspirational claims.

Authentication and access control

• Multi-factor authentication (MFA) enforced for all organizers on dashboard, tournament, settings, and metrics routes via an AAL2 (Authentication Assurance Level 2) gate through Supabase Auth; passkey (WebAuthn) satisfies MFA, otherwise TOTP is required (`middleware.ts`).
• The administrative area is protected by passkey/WebAuthn authentication with HMAC-signed session cookies, separate from organizer authentication.

Database access control and isolation

• Row-Level Security (RLS) enforced on all tables; organizers can access only tournaments they own (`owner_id = auth.uid()`), with service-role access confined to code-authenticated route handlers.
• Cross-user isolation verified by automated end-to-end security tests (one user cannot access another user's tournaments via API or UI; cross-user attempts return 404).

Encryption

• In transit: TLS enforced; HTTPS-only with HSTS `max-age=63072000` (2 years), `includeSubDomains`, `preload` (`next.config.mjs`).
• At rest: Supabase/PostgreSQL encryption at rest (AWS default); MFA TOTP secrets encrypted by Supabase Auth.

Network and application resilience

• Rate limiting: 60 requests/minute per IP general; 10 attempts/minute per IP on authentication endpoints (Upstash Redis-backed or in-memory fallback).
• Circuit breakers and retries for external dependencies (Stripe, Supabase) with exponential backoff; request timeouts (15s default) to prevent hung dependencies.

Logging, audit, and data-subject rights

• Immutable audit trail (`audit_events`) recording key actions (tournament create/delete, team generate, score delete, data erasure) with actor, IP, request ID, timestamp, and anonymized metadata.
• Right-to-erasure endpoint anonymizes registrant PII to an `[erased]` placeholder and logs the erasure event with a count (not the raw email).
• Self-serve data export for organizers (registrations and results).
• Structured JSON logging with pseudonymized user IDs and no secrets/PII in log payloads.

Application security

• Strict Content-Security-Policy, X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy, and a restrictive Permissions-Policy (`next.config.mjs`).
• No hardcoded secrets — all sensitive configuration via environment variables; Stripe webhook signatures verified (HMAC-SHA256).
• Input validation (e.g., RFC-style email validation on erasure) and HTML escaping in email templates.

Verification, vulnerability management, and continuity

• Automated dependency scanning in CI (`npm audit --audit-level=high`) plus Dependabot, and a Playwright security test suite (auth walls, cross-user isolation, RLS).
• Backups: Supabase managed PostgreSQL with automated daily backups (RPO ~24h, RTO target ~4h). Point-in-time recovery is available from Supabase but is NOT currently enabled. Quarterly restore tests are not currently performed.
• Health monitoring endpoint (`/api/health`), structured JSON application logging, Sentry error capture, and operator push alerts (Pushover) on scheduled-job failures. _Distributed tracing and external metrics export are NOT currently enabled (the custom OpenTelemetry pipeline was removed for stability); no trace/metric data is sent to any external APM today._

Honest limitations (stated for accuracy): ScrambleSync does not currently hold SOC 2, ISO 27001, or PCI-DSS Level 1 certifications. PCI scope is SAQ-A (card data handled entirely by Stripe). No formal third-party penetration test has been performed (automated scanning and the e2e security suite are in place instead).

Annex III — List of Sub-processors

The Customer authorizes the engagement of the following sub-processors (Clause 9, Option 2 — general written authorisation; 30 days' notice for changes). Each processes the personal data necessary for its stated function only.

• Supabase (AWS, us-west-1): PostgreSQL database, authentication, file storage, RLS. Handles all personal-data categories except card data. Primary US data location.
• Stripe (global; PCI-DSS Level 1 certified): Payment processing. Receives payment amount/currency, session and payment-intent IDs, product descriptions, and (if captured) customer email. Card data (PAN/CVV) is handled solely by Stripe and never reaches ScrambleSync (SAQ-A).
• Resend (global; GDPR-compliant): Transactional email. Sees recipient email address and name, plus template context (event/course/team names, codes, amounts, verification/reset links).
• Cloudflare (global edge): CDN, DNS proxy, DDoS protection, TLS termination, edge caching. Handles request metadata (IP, user agent, referrer, request path).
• Sentry (Sentry.io SaaS): Error and performance monitoring. Receives stack traces, request context (request ID, user ID, URL), exception details, and breadcrumbs.
• Upstash (managed Redis; us-east-1 default, configurable): Distributed rate-limiting and circuit-breaker state. Stores ephemeral rate-limit counters keyed by IP; no long-term personal data at rest.
• DigitalOcean (App Platform; default us-west): Application hosting and log capture. Handles application logs (JSON lines with pseudonymized user IDs) and organizer-set environment values; no direct database data.

_No external APM / tracing sub-processor is engaged today: distributed tracing and external metrics export are not currently enabled (the custom OpenTelemetry pipeline was removed for stability). Should such a provider (e.g., Grafana Cloud, Honeycomb, Datadog) later be enabled, it becomes a sub-processor and is disclosed here with the applicable change notice._

The current authoritative sub-processor list is maintained in the ScrambleSync DPA / sub-processor page.

UK International Data Transfer Addendum (IDTA) Note

For Customers subject to the UK GDPR (transfers of UK personal data outside the United Kingdom), the EU SCCs incorporated above are extended by the UK International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, issued by the UK Information Commissioner's Office (ICO) under section 119A of the Data Protection Act 2018 (the "UK Addendum"), version B1.0, in force 21 March 2022.

Under this Note:

• The UK Addendum is incorporated by reference and applies on top of the Module Two SCCs above for UK transfers.
• Table 1 (Parties) and the parties' details are as set out in Annex I.A.
• Table 2 selects the EU SCCs (Module Two) as the "Approved EU SCCs" being amended by the Addendum.
• Table 3 (Appendix information) is populated by Annexes I.B, II, and III above.
• Table 4 (Ending the Addendum): either party may end the Addendum if the ICO issues a revised approved addendum, as permitted by the Addendum.
• For UK transfers, the competent supervisory authority is the UK Information Commissioner's Office (ICO), Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF, and references to the GDPR are read as references to the UK GDPR and the Data Protection Act 2018.

Swiss FADP Adaptation Note

For Customers subject to the Swiss Federal Act on Data Protection (FADP / revFADP) (transfers of personal data from Switzerland), the EU SCCs incorporated above apply with the following adaptations, consistent with the guidance of the Swiss Federal Data Protection and Information Commissioner (FDPIC):

• The FDPIC is the competent supervisory authority for transfers governed by the FADP.
• References in the SCCs to the "GDPR" are understood as references to the FADP to the extent the FADP applies.
• References to EU Member State law and to the courts/supervisory authorities of an EU Member State are read as references to Swiss law and to the competent Swiss authorities and courts, where the FADP governs the transfer.
• The Clauses also protect the personal data of legal entities (juristic persons) until the relevant provisions of the FADP are amended or repealed, reflecting the broader Swiss scope.
• Where a transfer is subject to both the GDPR and the FADP, the SCCs apply in parallel: the EU regime (with the EU/Irish authority and law) for the GDPR portion and the Swiss adaptations above for the FADP portion.

C. EU Data Residency

This section states the position accurately. Two distinct things are often confused — please read both.

1. Lawful handling of EU/EEA personal data — available TODAY.

ScrambleSync currently hosts its database and authentication on Supabase / AWS in the United States (us-west-1), with the additional sub-processors listed in Annex III. EU/EEA (and UK and Swiss) personal data can be processed lawfully today because the appropriate transfer safeguard is in place: the EU SCCs (Module Two) incorporated above, extended by the UK IDTA and the Swiss FADP adaptations as applicable, and backed by the technical and organisational measures in Annex II. In other words, lawful EU-data handling does NOT require EU hosting — it is achieved through these contractual safeguards plus the security controls, even though the data physically resides in the US.

2. Physical EU data residency (data stored in an EU region) — a SEPARATE, OPTIONAL capability, on request.

"Data residency" means the data is physically stored within the EU/EEA (an EU cloud region) rather than the US. This is a different requirement from lawful transfer, and some customers (often public-sector or regulated organizations) require it as a matter of policy.

• It is NOT the current default. ScrambleSync's standard deployment stores data in the US (AWS us-west-1). We do not claim EU hosting as the default configuration.
• It is available as an optional capability on request. For customers who require physical EU residency, ScrambleSync can be provisioned as a dedicated EU-region instance (e.g., a Supabase project in an EU region such as Frankfurt/`eu-central-1`), keeping the primary database and authentication data within the EU/EEA.
• Scope and caveats (stated honestly): A dedicated EU-region instance is provisioned on request and is subject to a separate arrangement (commercial terms and lead time). Certain sub-processors are inherently global (e.g., Stripe, Cloudflare's edge network) or default to other regions (e.g., Upstash `us-east-1`, the optional OTLP/APM endpoint); for these, the SCCs remain the governing transfer mechanism even on an EU-residency deployment. Customers requiring strict EU-only data flows should discuss the specific sub-processor configuration with ScrambleSync before relying on it.

Bottom line: Use ScrambleSync with EU data lawfully right now via the SCCs (no EU hosting needed). If your organization additionally requires the data to physically live in the EU, ask us — we can stand up a dedicated EU-region instance as an optional, on-request configuration.