Sub-processors

Third-party services that process Enrollo customer data on our behalf.

Last updated: May 4, 2026

Each sub-processor receives only the data needed to provide its service. Contracts incorporate UK GDPR / EU GDPR data-processing terms and standard contractual clauses where relevant.

Changes and notice

We will give at least 30 days' written notice to customers before engaging a new sub-processor or replacing an existing one. Controllers may object on reasonable grounds related to protection of Customer Personal Data; if the objection cannot be resolved within 30 days of the notice, the Controller may terminate the affected service with no penalty. This is the sub-processor clause of our Data Processing Agreement.

To subscribe to change notifications, email hello@enrollo.io with subject "Subprocessor notifications".

ServicePurposeData categoriesLocation
SupabaseDatabase (PostgreSQL) for student records, applications, documents, timeline events.All agency dataAWS EU (eu-west-1)
ClerkAuthentication, session management, 2FA, invite flows.Account identifiers (email, name), session tokensAWS US / EU
VercelApplication hosting and delivery (Next.js runtime, edge network).Request logs, IP addresses, function logsGlobal edge, primary EU
PolarSubscription billing and payment processing.Billing contact, payment metadata (no card numbers stored by us)EU
SentryProduction error tracking. PII scrubbed at SDK level.Error stacks, sanitised request metadataUS
PostHogProduct usage analytics. Anonymised where feasible, no student PII.Feature usage events, org-level aggregatesEU (eu.posthog.com)
ResendTransactional email delivery (invites, password reset, handover notifications).Recipient email addresses, email contentUS
Gotenberg (self-hosted)PDF rendering for invoices and reports.Report snapshot payloads at render time; no persistenceRender.com EU region

Erasure handling (Article 17)

When an agency owner deletes an organization or a student from Enrollo, here's what happens at each sub-processor. The path combines automatic cascade where Enrollo controls the data, with documented retention windows where the sub-processor controls its own platform logs.

One statutory exception: invoice and payment records retained 7 years to meet EU/UK financial recordkeeping obligations (overrides Article 17 per Article 17(3)(e)). Non-financial PII is erased on request.

ServiceOn erasure request
SupabaseCascade delete on org or student erasure (immediate). Point-in-time recovery snapshots auto-expire on the Supabase plan's retention window (typically 7 days).
ClerkAccount-level erasure on user request via Clerk's account settings. Enrollo does not store Clerk identifiers after org deletion (Supabase members row cascades).
VercelFunction logs auto-expire within 30 days per Vercel's platform retention. No customer-controllable purge — the 30-day window applies uniformly.
PolarStatutory retention: invoice and payment records retained for 7 years to meet EU/UK financial recordkeeping obligations (overrides Article 17 per Article 17(3)(e)). Non-financial PII deleted on erasure request.
SentryEvents auto-expire at 90 days per Enrollo's Sentry retention setting. Student/org identifiers are not attached to Sentry events (PII scrubbed at SDK level), so erasure is structural rather than per-record.
PostHogUser-level deletion via PostHog's GDPR-compliant deletion endpoint on request to hello@enrollo.io. No student PII captured; events are tied to anonymised counselor sessions only.
ResendEmail send logs auto-expire within Resend's retention window (typically 30 days). No persistent contact lists are maintained — every send is transactional.
Gotenberg (self-hosted)Stateless service — payloads exist only during the render request and are not persisted. Nothing to erase.

Erasure requests are exercised through the Enrollo app: Settings → Delete organization (org-wide) or the per-student permanent-delete flow on archived students. For questions or to escalate a request, email hello@enrollo.io.