Sub-processor DPA + Sub-processor Register

This page names every provider ("sub-processor") that processes personal information on our behalf. The Sub-processor register at the bottom is the current, published source of truth for the Privacy Policy §5.1 list and the Notice at Collection page. The Addendum body sets out the standard data-processing terms we apply with each provider, tied to our Privacy Policy commitments around Sensitive Personal Information (SPI), the AI-tier carve-out, and CCPA/GDPR audit obligations.

Last updated: 2026-08-11

Addendum body

These are the standard data-processing terms we apply with each sub-processor named in the register below. Bracketed fields (e.g. [SUB-PROCESSOR LEGAL NAME]) are completed for the specific provider when the terms are executed. The current list of sub-processors is the Sub-processor register at the end of this page.

This Sub-processor Data Processing Addendum ("Addendum") is entered into between All You Can App, Inc., a Delaware corporation ("Controller"), and [SUB-PROCESSOR LEGAL NAME] ("Processor"), and supplements the [BASE AGREEMENT TITLE AND DATE] between the parties. In the event of conflict, this Addendum controls with respect to the processing of Personal Information on Controller's behalf.

1. Definitions

Terms not defined here have the meanings given in the Base Agreement or in the applicable Data Protection Laws.

• "Data Protection Laws" means the California Consumer Privacy Act / California Privacy Rights Act ("CCPA/CPRA"); the EU and UK General Data Protection Regulations ("GDPR"); the Swiss Federal Act on Data Protection ("FADP"); and any successor or comparable statute applicable to the processing.
• "Personal Information" has the meaning given by the applicable Data Protection Law (including CCPA §1798.140(v) and GDPR Art. 4(1)).
• "Sensitive Personal Information" ("SPI") has the meaning given by CCPA §1798.140(ae) and includes, for this Addendum, the self-reported mental and physical health information described in Controller's Privacy Policy §3.7.
• "Processing," "Controller," "Processor," "Sub-processor," and "Data Subject" have the meanings given by GDPR Art. 4 (or the equivalent under CCPA where applicable).
• "Services" means the services Processor provides to Controller under the Base Agreement.

2. Scope and roles

For the Personal Information that Controller transmits to Processor under the Base Agreement:

• Controller is the business under CCPA and the controller under GDPR.
• Processor is the service provider under CCPA and the processor under GDPR.

Processor will Process Personal Information only on Controller's documented instructions, only for the permitted purposes in Section 4, and only for the duration of the Base Agreement (plus any period required for deletion or return under Section 11).

3. Categories of Personal Information processed

Processor processes the following categories on Controller's behalf:

The actual scope for this Processor is narrower than the full list above. The specific categories Processor receives are listed in Schedule A.

4. Permitted purposes

Processor may Process Personal Information only:

• To provide the Services to Controller as described in the Base Agreement;
• To detect and prevent fraud, abuse, and security incidents;
• To comply with applicable law and binding legal process;
• To maintain Processor's reasonable backup, business-continuity, and security operations; and
• For any other purpose specifically and in writing instructed by Controller.

Processor will not:

• Sell or share Personal Information (CCPA §1798.140(ad), §1798.140(ah));
• Use Personal Information for cross-context behavioural advertising;
• Combine Personal Information received under this Addendum with Personal Information that Processor receives from other sources or in connection with other business purposes, except as strictly necessary to provide the Services;
• Retain, use, or disclose Personal Information outside the direct business relationship with Controller.

5. Sensitive Personal Information — additional restrictions

For SPI (the categories marked "Yes" in Section 3), Processor will additionally:

• Limit Processing to what is strictly necessary to provide the Services to Controller;
• Not disclose SPI to any third party, including affiliates, except Sub-processors authorised under Section 8;
• Not use SPI to develop, train, fine-tune, evaluate, or benchmark any machine-learning model whose weights, parameters, or outputs benefit any person other than Controller and Controller's authorised end users;
• For AI/ML-tier providers specifically (e.g. Anthropic):
  • SPI may be used only for inference at runtime to serve the requesting end user;
  • SPI must not be retained beyond what is required for the immediate Service operation, and in no event longer than 30 days;
  • SPI must not appear in any logging, analytics, evaluation dataset, fine-tuning corpus, or model-training pipeline;
  • Processor will provide written confirmation of these protections on request, on at least an annual basis.

6. Data subject rights

Processor will assist Controller in responding to verifiable data subject requests under CCPA §1798.110–106 and GDPR Arts. 15–22 (access, deletion, correction, portability, restriction, objection, and limitation of SPI use) by:

• Implementing the access mechanism described in Schedule B (API, endpoint, console, or ticketed process);
• Acting on documented deletion or correction instructions from Controller within 30 days;
• Not responding directly to data subjects, except to acknowledge receipt and refer them to Controller (unless legally required otherwise);
• Honouring Global Privacy Control signals where Processor's Services include first-party traffic ingestion;
• Cooperating with reasonable Controller audits to demonstrate compliance.

7. Security

Processor will implement and maintain appropriate technical and organisational measures designed to protect Personal Information, including at minimum:

• Encryption in transit (TLS 1.2+) for all Personal Information transmitted to or from Processor;
• Encryption at rest for production data stores;
• Access control under the principle of least privilege; multi- factor authentication for production access;
• Audit logging of administrative access to Personal Information and security-relevant events; logs retained for at least 365 days;
• Vulnerability and patch management with documented timelines;
• Annual third-party security audit (SOC 2 Type II, ISO 27001, or equivalent) — report provided to Controller on request, subject to reasonable confidentiality controls;
• Employee security training appropriate to the role;
• Background screening for employees with access to production systems, to the extent permitted by law.

8. Sub-processors

Processor may engage Sub-processors only if:

• Each Sub-processor is bound by contractual terms no less protective than those in this Addendum;
• Processor remains liable to Controller for the acts and omissions of its Sub-processors as if they were its own;
• Processor maintains a current list of Sub-processors handling Controller's Personal Information and makes that list available to Controller on request;
• Processor provides at least 30 days' prior written notice of any new Sub-processor or change to Sub-processor scope that materially affects Controller's Personal Information, giving Controller a reasonable opportunity to object;
• If Controller reasonably objects, the parties will negotiate in good faith; if no resolution is reached, Controller may terminate the affected Services without penalty.

9. International transfers

For transfers of Personal Information from the EEA, the UK, or Switzerland to a third country that has not received an adequacy decision, the parties incorporate by reference the EU Standard Contractual Clauses (Implementing Decision 2021/914), UK International Data Transfer Addendum, and Swiss equivalents, with the modules and roles selected per Schedule C.

For data subjects in California or other US states with comprehensive privacy laws, Processor confirms that it is bound by this Addendum to provide privacy protections at least equivalent to those available in the originating jurisdiction.

10. Incident response

Processor will:

• Notify Controller in writing of any confirmed security incident affecting Personal Information without undue delay and in any event within 72 hours of becoming aware;
• Provide a description of the incident, the categories and approximate number of data subjects and records affected, the measures taken or proposed to address the incident, and the contact point for further information;
• Cooperate with Controller's investigation and reasonable remediation;
• Not make any public statement attributing the incident to Controller without Controller's prior written consent, except as required by law.

11. Return and deletion

On termination of the Base Agreement, or earlier on Controller's written request, Processor will, at Controller's option, return or securely delete all Personal Information in Processor's possession or control:

• Within 30 days for live production data;
• Within 35 days for routine-rotation backups; backups beyond that window may be retained only if isolated, encrypted, and protected from active processing, and will be deleted on their normal rotation;
• Processor will provide written certification of deletion on request.

12. Audits

Controller (or an independent third-party auditor under reasonable confidentiality terms) may audit Processor's compliance with this Addendum once per calendar year on at least 30 days' written notice, plus any time after a confirmed security incident materially affecting Controller's Personal Information.

Processor's then-current SOC 2 / ISO 27001 / equivalent report satisfies the routine audit right, provided the scope is sufficient to evaluate compliance with this Addendum.

13. Liability and indemnification

The liability and indemnification provisions in the Base Agreement apply. Notwithstanding any general liability cap in the Base Agreement, Processor's liability for breach of this Addendum, to the extent the breach involves a violation of Data Protection Laws or a confirmed unauthorised disclosure of SPI, is not subject to the general cap and is in addition to any statutory remedies available to Controller or affected data subjects.

14. Order of precedence

If there is a conflict between this Addendum and the Base Agreement, this Addendum controls with respect to the Processing of Personal Information.

15. Governing law and disputes

This Addendum is governed by the law of Delaware, USA, and any dispute is resolved under the dispute-resolution mechanism set out in the Base Agreement. The choice of law does not deprive a data subject of the protections of their local law where mandatory.

16. Signatures

For Controller — All You Can App, Inc.:

Name: ____________________________ Title: ____________________________ Signature: _______________________ Date: _____________________________

For Processor — [SUB-PROCESSOR LEGAL NAME]:

Name: ____________________________ Title: ____________________________ Signature: _______________________ Date: _____________________________

Schedule A — Categories of Personal Information processed by this Processor

Fill in per-processor. Below is the recommended starting list for each sub-processor in our current Privacy Policy §5.1. Strike through any category the Processor does not in fact receive.

Supabase (database, authentication, file storage)

• Identifiers (name, email, account ID, IP address)
• Customer records (billing metadata)
• Commercial information (subscription state)
• Internet activity (session data, audit logs)
• Approximate geolocation (city-level)
• Inferences (zone classification, stage-of-change)
• Sensitive Personal Information (self-reported mental/physical health, chronic-condition data, toolkit answers, check-in content)

Vercel (web hosting, edge compute)

• Identifiers (IP address, request headers)
• Internet activity (request logs, error traces)

Stripe (payment processing)

• Identifiers (name, email)
• Customer records (billing name, billing address, payment-method metadata)
• Commercial information (subscription tier, purchase history, refunds)

RevenueCat (cross-channel subscription & entitlement management; mobile in-app purchases + Stripe reconciliation)

• Identifiers (RevenueCat "app user id" = the Director's account ID / auth.uid; store transaction identifiers returned by Apple / Google / Stripe).
• Customer records + commercial information (subscription tier, purchase and renewal history, entitlement state, refund status) reconciled across the App Store, Google Play, and Stripe billing channels.
• Device / app-install identifiers RevenueCat receives from the mobile SDK for purchase attribution.
• No email, IP address, check-in content, project content, free-write text, health self-reports, or other Director-typed content is transmitted to RevenueCat.
• Onward sub-processors — Apple App Store (StoreKit) and Google Play Billing are the payment processors for mobile in-app purchases; RevenueCat is the reconciliation / entitlement layer between the Service and those stores. Stripe (above) remains the web payment processor and is connected to RevenueCat for a unified purchase-history view.

Resend (transactional email)

• Identifiers (name, email)
• Limited commercial information (event triggering the email)

Anthropic (AI features on Always-on AI / Calibration Burst tiers only)

• Identifiers (synthetic session ID; no email or account ID transmitted)
• The Director's input content for the current AI session, which may include Inferences and Sensitive Personal Information (zone, check-in text, toolkit, condition tags) — sent only for inference at runtime, never retained beyond 30 days, never used for training (see Section 5)

Deepgram (voice input — speech-to-text on all tiers)

• Identifiers (synthetic session ID; no email or account ID transmitted)
• Audio captured when the Director uses voice input on check-ins, free-writes, or the "Check in with AI" surface, plus the resulting transcribed text. Audio and transcripts may include Sensitive Personal Information (mental health self-reports, dimension signals) and are sent only for transcription return.
• Load-bearing invariant — MIP opt-out. Controller sends mip_opt_out=true on every request to the Deepgram /v1/listen endpoint. This opts audio and transcripts out of Deepgram's Model Improvement Program (which is enabled by default for hosted-API customers) so that audio is NEVER retained for model training. A build-fail guard test in Controller's codebase asserts the flag is present on every request path; any commit that removes the flag fails CI.
• With mip_opt_out=true in place, Deepgram retains audio only for the duration necessary to process the request. Not used to train Deepgram's models.

OpenAI (text-to-speech on Always-on AI / Calibration Burst tiers only)

• Identifiers (synthetic session ID; no email or account ID transmitted)
• The AI-composed response text rendered to audio for playback to the Director. May reference summarised state or coaching language; not used to train OpenAI's models under the API zero-retention terms

Twilio (SMS notifications on all tiers, opt-in; per-tier monthly caps)

• Identifiers (Director phone number in E.164 format)
• Message body (notification copy — may reference Director state classifications and project / task names if Director enabled those notification types; never includes free-write or check-in text verbatim)
• Delivery metadata (timestamps, segment counts, delivery status, inbound replies — STOP / HELP / etc.)
• TCPA opt-in timestamp + consent text version retained as audit trail; not transmitted to Twilio

Expo (Expo Application Services — mobile push notification delivery proxy)

• Identifiers (Director's Expo push token — an opaque per-device- install identifier), device platform (ios or android).
• Push payload (notification title, body, data object used for deep-link routing on tap). Payloads reference structural strings only (routine block name, mini-goal title, zone label). Never contains free-write text, check-in narrative, project notes, or any other Director-typed content.
• No email, account ID, IP address, or password ever transmitted.
• Onward sub-processors — Apple APNs (iOS deliveries) and Google FCM (Android deliveries). Expo forwards the payload to Apple's Push Notification service or Google's Firebase Cloud Messaging as the platform-native delivery leg. Apple and Google are bound by their own device-owner terms; Controller does not have a direct DPA with either for this proxy path.
• Optional environment variable EXPO_ACCESS_TOKEN if configured unlocks Expo's higher rate limit and delivery-receipt API; the token itself is a service credential, not Director data.

Google LLC (Google Calendar API; only when Director authorises calendar integration)

• Identifiers (Director's Google account email at OAuth-grant time, required by Google's OAuth flow; not stored beyond the OAuth exchange)
• OAuth refresh token + scopes (encrypted at rest before storage)
• Calendar event content written by the Service to the Director's calendar: project name, task name, time blocks, optional reminder text. No Director free-write or check-in text is written to the calendar.
• With opt-in pull / two-way only: event metadata read from the Director's calendar (start/end times, busy/free status). Attendee names and email addresses are explicitly NOT read.

Discord Inc. (community server hosting; only when Director voluntarily links their Discord account)

• Director's Discord user ID (numeric identifier returned by Discord OAuth identify scope), persisted on the directors row alongside a link timestamp.
• Role state we sync (Trial / Subscriber / AI tier), recomputed from the Director's All You Can App subscription status + calibration window state on every Stripe webhook fire and daily reconciliation cron. The Discord role is tied to the Director's All You Can App paying tier, not to any Discord-side purchase, boost, or paid arrangement.
• No Director email, account ID, IP address, check-in content, project content, free-write text, or other Personal Information is transmitted to Discord by the Service.
• Linking is optional and not required to use any Service feature. The community server is free for any Director to join independent of All You Can App subscription status; the Discord role is the only thing tied to All You Can App subscription state.
• The Service is not affiliated with, sponsored by, or selling access to Discord Inc.; the community is a voluntary opt-in support space. Director's use of Discord is independently subject to Discord's own Terms of Service and Privacy Policy.

Schedule B — Data subject request handling mechanism

Per-processor. Describe whether requests are handled via:

• Controller's self-service (request is acted on inside the Controller's app, with no Processor involvement)
• Processor API (Controller calls a Processor endpoint to action the request)
• Console / dashboard (Controller logs into a Processor portal)
• Support ticket (Controller emails or files a ticket with Processor)

For each, list the SLA (e.g. "within 7 days of receipt") and the escalation path if the SLA is missed.

Schedule C — International transfer mechanism

For each Processor, identify the operative transfer mechanism:

Confirm Transfer Impact Assessment (TIA) is on file for each non- adequacy-decision route.

Sub-processor register

The current source of truth for the Privacy Policy §5.1 list and the Notice at Collection page. The Governing DPA column names the standard DPA under which each provider processes personal information on our behalf. "Last reviewed" is the date this register row was last checked.

Owner: All You Can App, Inc. — support@allyoucan.app Cadence: review on every new sub-processor; full audit annually.

The current list of sub-processors above is the published disclosure; it is kept in sync with the Privacy Policy §5.1 list and the Notice at Collection page.