Starter privacy policies say "we may share your data with trusted third parties". Regulators and careful customers read that as "we did not check". GDPR Article 13 asks you to name the recipients or categories of recipients of personal data, and enterprise buyers will ask for your subprocessor list anyway.
The trouble is keeping the list true. It is written once, before launch, and then someone adds error monitoring, a support widget and a second email provider, and nobody opens the policy again.
Make the integration own its line
Keep the list in code, next to the rest of the site's copy:
// src/lib/site.ts
export interface ServiceProvider {
name: string;
purpose: string;
url: string; // the vendor's own privacy policy
}
const serviceProviders: ServiceProvider[] = [
{ name: "Vercel", purpose: "Hosting and content delivery", url: "https://vercel.com/legal/privacy-notice" },
{ name: "Stripe", purpose: "Payment processing", url: "https://stripe.com/privacy" },
{ name: "Sentry", purpose: "Error monitoring", url: "https://sentry.io/privacy/" },
];
The privacy page renders it as a table. The rule that keeps it honest: the change that adds an SDK which sends user data somewhere also adds its line here. In a generated repo each battery does this through a slot, so selecting Stripe or PostHog adds them and removing them takes them off.
One company can arrive more than once (Supabase for the database, auth and storage). Merge by name before rendering, joining the purposes, so the table lists each company once.
What belongs on the list
A service belongs on it when your users' personal data reaches it: names, emails, IP addresses, payment details, support messages, uploaded files, analytics events, error reports that carry a user id, prompts sent to an AI model. Hosting counts. A library you run on your own server does not.
Sign-in with Google, GitHub or Microsoft is a different case. Those providers send data to you rather than process it for you, so the policy says what you receive from them instead of listing them as processors.
The rest of the policy
A policy that satisfies most SaaS products under GDPR and the California laws covers: who you are, what you collect, why and on what legal basis, cookies, who processes it (the list above), international transfers, how long you keep it, the user's rights, how to use them and how fast you answer, security, children, changes, and contact details. Keep the effective date a literal string you update by hand, not the build date.
None of this replaces a lawyer. It gives the lawyer an accurate draft to review, and it keeps the vendor list accurate after they have.