Subprocessor and International Transfer Schedule

1. How to read this schedule

A subprocessor processes Customer Data for Votegrain. A separate service provider may process Votegrain's own controller data, such as billing contacts or a sales enquiry. This schedule identifies the role and scope rather than describing every vendor as a subprocessor.

Do not list an integration as active merely because source code supports it. A provider is current only after the live configuration, contracting legal entity, purpose, data categories, regions, DPA, downstream providers, retention and transfer posture are verified. Conditional providers apply only when the named feature is enabled.

Every stated first-pilot region, retention and control is an activation condition. If the connected evidence differs, Votegrain must update and reapprove this schedule or disable the affected provider before Customer Data enters the service.

2. Core service — Supabase

• Provider/legal entity: Supabase, Inc.
• Purpose: managed Postgres database, authentication and related platform services used by the connected product project.
• Customer Data: accounts, memberships, invitations, initiatives, options, attributes, ballots, results, reports, shares, audits and other service records stored by the Customer.
• Primary region: West EU (London), eu-west-2. A paid pilot must not begin until the exact customer-production project binding and region are read back and recorded in the activation evidence.
• Backups and support: daily physical backups associated with the London customer-production project are available on a rolling seven-day basis. Supabase and its listed providers may perform limited support and infrastructure operations in the locations described by its current DPA and subprocessor list.
• Contract and transfer: Supabase's standard DPA incorporates the applicable EU standard contractual clauses and UK Addendum for restricted transfers. Votegrain must retain the current accepted terms, provider list and transfer assessment with the pilot evidence.

3. Core service — Vercel

• Provider/legal entity: Vercel Inc.
• Purpose: application and website hosting, request processing, content delivery, deployment and operational platform services.
• Customer Data: encrypted request/response content in transit through the application, service-generated logs and any data intentionally placed in enabled platform features. The application should minimise Customer Data in logs.
• Locations and retention: the connected serverless function region is iad1 in the United States. Vercel's DPA describes United States primary processing and global content-delivery, support and subprocessor operations. Customer content is not intentionally written to logs; transient operational logs containing diagnostic metadata are retained for no more than 30 days under Votegrain's first-pilot policy.
• Contract and transfer: Vercel's DPA incorporates the applicable EU standard contractual clauses and UK international-transfer terms. Votegrain must retain the current terms, provider list, change-notice route and transfer assessment with the pilot evidence.

4. Core transactional email — Resend

• Provider/legal entity: Plus Five Five, Inc., trading as Resend.
• Purpose: transactional invitations, authentication and service email, and delivery-status webhooks. Ballot choices and unnecessary decision content must not appear in email.
• Data: recipient email, sender, subject/template content, message and delivery identifiers, timestamps and delivery/security metadata. Do not include ballot choices or unnecessary decision content in email.
• Locations and retention: the connected sending region is Ireland. Resend states that account data, logs and API records are stored in the United States and that email data is retained for 30 days. Ireland sending does not mean all storage or support stays in Ireland.
• Contract and transfer: Resend's current DPA incorporates the EU standard contractual clauses and UK Addendum. Votegrain must retain the accepted DPA, current subprocessor list, change-notice route and transfer assessment with the pilot evidence.

5. Diagnostic monitoring — Sentry

• Provider/legal entity: Functional Software, Inc., trading as Sentry.
• Purpose: error and performance monitoring for the connected product deployment.
• Data: redacted diagnostic events, routes, technical context and pseudonymous identifiers. The application must not intentionally send ballot content, authored decision text, access tokens or direct identifiers. Scrubbing must remain enabled and sample payloads form part of activation evidence.
• Locations and retention: the connected Sentry organisation is in its Germany region with 30-day event retention. Session replay and attachments are disabled.
• Contract and transfer: the current Sentry DPA and subprocessor terms must be accepted and retained before Customer Data enters the pilot. If that evidence is absent, Sentry must be disabled for the pilot.

6. Disabled service — OpenAI

• First-pilot status: disabled. OpenAI receives no Customer Data under the standard Pilot Order.
• If later enabled for a UK Customer, the published API contracting entity is OpenAI OpCo, LLC. A new signed Order must identify the exact feature, API project, endpoint, regional control, input categories, model policy, DPA, subprocessors and transfer safeguard.
• Potential data boundary for a later Order: authoring checks may include initiative titles and descriptions, option text, links, custom fields and organisation standards; post-result features use approved aggregates and sanitised labels. Raw ballots and identities must not be sent by design.
• Published default posture for a later Order: API data is not used to train OpenAI models by default and abuse-monitoring logs may retain customer content for up to 30 days. `store: false` does not prove Zero Data Retention, regional processing or absence of a restricted transfer.

7. Disabled commercial service — Stripe

• First-pilot status: disabled. The Customer is billed by manual GBP invoice and bank transfer, so Stripe receives no first-pilot Customer Data and no Stripe receipt can activate the service.
• A later live checkout requires a new or amended Order that identifies the connected Stripe contracting entity, controller and processor roles, services, countries, retention, provider list and transfer terms.
• The future data boundary is limited to Customer legal and billing contacts, Order reference, amounts, tax and invoice, subscription or payment identifiers. Ballots, participant attributes and decision content must not be sent to Stripe, and Votegrain must not receive or store full card details.

8. Website demo-request providers

The demo-request form has a separate, approved and purpose-limited privacy notice. It identifies the website's Vercel hosting, isolated London Supabase project, Resend alert, Google Workspace mailbox and bounded mailbox-agent path, with 12-month Supabase enquiry retention. Those facts do not establish the product application's Customer Data schedule and must not be copied across without separate verification.

9. Transfer and residency record

• For each active provider record: data exporter/importer, controller/processor role, data and data subjects, destination countries, frequency, onward transfer, storage/support locations and technical measures.
• For a UK restricted transfer: record adequacy or the executed UK IDTA/Addendum, the EU SCC module if used, and the current transfer risk assessment/data-protection-test reference.
• For an EEA restricted transfer: record adequacy or the applicable 2021 EU SCC module and transfer impact assessment.
• For an Australian cross-border disclosure: record the overseas recipient countries, reasonable steps/contractual protections and APP 8 accountability analysis.
• A regional primary database is only one line in the residency record. Application requests, support, logs, email, payment, AI, replicas and backups need their own accurate entries.

10. Provider change process

The DPA gives general authorisation only for this schedule. Votegrain will give at least 30 days' notice to the Customer's legal or privacy contact recorded in the Order before a new or replacement subprocessor begins materially different processing.

A Customer may object during that period on reasonable, documented data-protection grounds. The parties will try for 15 days to agree an alternative or configuration change. If they cannot, the Customer may stop the affected optional feature or terminate the affected Order before the new provider begins, receive a refund of prepaid fees for the unused terminated period, and use the DPA export and deletion process. An urgent replacement needed for a security incident, law, provider failure or material risk may occur sooner, with notice as soon as reasonably practicable.

The schedule version, effective date and release hash must change when an active provider, purpose, material data category, destination or transfer safeguard changes. Merely editing this page is not proof that required vendor terms or assessments exist.

11. Activation and review evidence

• Connected production configuration and region read-back for every active provider before Customer Data enters the service.
• Current accepted provider terms and DPA, contracting entity, subprocessor list and change-notice route.
• Sample/sanitised payload verification showing what data is actually sent.
• Retention, deletion, backup, support-access and incident facts supported by the plan and configuration in use.
• Transfer map and approved safeguard/data-protection assessment for each restricted route.
• Named owner and review date for quarterly and event-driven schedule review.