Current vendor and subprocessor register.
The current vendor register: what each identified provider receives, its purpose, and its role.
| Provider | What it does | What it receives | Role | Location and transfer status | Applies to |
|---|---|---|---|---|---|
| Vercel | Website hosting, the free scan, and traffic protection | Requests to strongprivacy.com, including IP addresses; web addresses submitted to the free scan and what the scan observes | Service provider for hosting; its own security and network operations may involve separate controller activity under its terms | Contracted regions and onward providers must be confirmed before this draft is approved | Everyone who visits strongprivacy.com |
| Turso (libSQL) | Database | Accounts, workspaces, configurations, scan results and consent evidence | Intended subprocessor | Database region, legal entity and transfer safeguard must be confirmed before production | Every workspace |
| Stripe | Card billing | Workspace owner’s email, organization name, plan, invoices and payment details | Processor or independent controller depending on the payment, fraud and compliance activity | See the executed Stripe terms and current subprocessor list; confirm the applicable transfer safeguard | Workspaces that pay by card |
| Shopify | App Store billing and store connection | Shop name and domains, subscription state, theme and app settings | Platform provider; role varies between app processing, billing and Shopify’s independently determined operations | See the executed Shopify terms and current subprocessor list; confirm the applicable transfer safeguard | Workspaces installed from the Shopify App Store |
| Resend | Service email | Recipient email address and the message: confirmations, password resets, invitations and alerts | Intended subprocessor for email delivery | Contracting entity, processing locations and transfer safeguard must be confirmed before production | Every account |
| Sentry | Error reporting | When a request fails: the error and its stack trace, the HTTP method, the page or route template, and the request reference shown on the error page. Request bodies, cookies, headers, sign-in identities and credentials carried in a link are removed before the report is sent | Intended subprocessor for diagnostics | Contracting entity, the region the project stores events in, and the transfer safeguard must be confirmed before production | Only requests that fail. Enabled per deployment; a deployment without it keeps error records in its own server logs |
| Managed Redis (provider to be selected) | Rate limiting and caching of published site configuration | Short-lived request counters keyed by an irreversible hash of the caller, and a copy of the published consent configuration a site already serves publicly. No consent record, account or evidence | Intended subprocessor for ephemeral cache storage | Provider, region and transfer safeguard must be selected and confirmed before production | Optional. A deployment without it serves the same data from the database |
| OpenAI / Anthropic (Claude) / OpenRouter and its configured destination | Optional Nox workspace assistant | Questions, recent conversation messages, reviewed product guidance, and selected summaries of sites, scan status and findings, saved consent settings, and scan allowance. Raw visitor consent records, HAR captures, cookie values, and integration secrets are excluded | Potential AI subprocessors; only the configured provider receives Nox requests. OpenRouter additionally routes to its specified destination provider | Before enabling production processing, record the selected provider and destination legal entities, model, processing locations, retention terms, executed agreements and applicable transfer safeguards | Only questions sent from workspaces whose owner has enabled Nox for the current provider choice. Off by default; the selected provider and model are disclosed in Settings |
The final register will name each provider's contracting legal entity, processing purpose, data categories, role, processing locations, transfer safeguard and effective date. Deployment dependencies and data flows must be rechecked before this draft is approved and whenever the service changes.
The current draft proposes at least 30 days' notice before adding or replacing a subprocessor. The final notice and objection procedure must match the executed data processing addendum and customer contracts. To ask about the draft or request change notices, write to info@accessible.org.