GDPR processor list for tiny apps: who you have to name, where, and why

Under EU Regulation 2016/679 (GDPR), if you collect personal data from people in the EU, you are typically a “controller” and most of your indie-stack vendors are “processors”. Articles 13 and 14 spell out the information you have to provide to a data subject when you collect data from them, including the categories of recipients of personal data.

This post walks through what that actually means for a small app, with example wording you can adapt.

TLDR

GDPR Art. 13(1)(e) requires that you provide “the recipients or categories of recipients of the personal data, if any” at the time of collection. Most indie apps satisfy this with a named processor list inside the privacy policy. The regulation does not say you must name every individual processor, but most counsel-reviewed policies do name them — naming makes it easier for a data subject to exercise their rights under Art. 15 (right of access) and Art. 17 (right to erasure).

The text of Article 13 is published in the EU Official Journal (accessed 2026-05-25). Read it before deciding how granular your list should be.

Why the regulation cares about processors

Article 28 sets out the contractual relationship between you (the controller) and each processor (Stripe, Supabase, PostHog, OpenAI, etc.). Each of those vendors publishes a Data Processing Addendum (DPA) you typically accept when you sign up. The DPA is the legal commitment that the processor acts only on your documented instructions, applies security measures, and helps you respond to data-subject requests.

The processor list inside your privacy policy is the user-facing window into the same picture: who has hands on the data, even if they’re acting on your instructions.

A minimal processor list for an indie SaaS

Adapt this template — example wording, not legal advice.

Processors we use

We use the following service providers to operate our app. Each one acts on
our documented instructions under a Data Processing Addendum (DPA) and is
bound by appropriate security measures.

- Stripe Payments Europe, Ltd. (Ireland) / Stripe, Inc. (USA) — payment
  processing. https://stripe.com/privacy
- Supabase, Inc. (USA), region [your selected region] — database, authentication,
  and file storage. https://supabase.com/privacy
- PostHog Inc. (USA) / PostHog B.V. (Netherlands) — product analytics,
  feature flags, and (where enabled) session replay. https://posthog.com/privacy
- Resend, Inc. (USA) — transactional email delivery. https://resend.com/legal/privacy-policy
- OpenAI, L.L.C. (USA) — large-language-model inference for our AI features.
  https://openai.com/policies/privacy-policy
- Vercel, Inc. (USA) — hosting and edge runtime. https://vercel.com/legal/privacy-policy
- Cloudflare, Inc. (USA) — DNS, CDN, and bot protection. https://www.cloudflare.com/privacypolicy/
- Functional Software, Inc. dba Sentry (USA) — error monitoring.
  https://sentry.io/privacy/

For each provider above, we have a DPA in place where one is required and we
disclose the data shared as described in [Section X — What we collect].

What the regulation actually requires (paraphrased)

Per Article 13(1)(e) — verify against the official text:

• You must identify “the recipients or categories of recipients” of personal data.
• The categories alone may be enough; identifying recipients by name is considered best practice and is what most reviewers expect.

Per Article 13(1)(f):

• If you transfer personal data to a country outside the EEA without an adequacy decision, you must disclose the transfer mechanism (Standard Contractual Clauses, Binding Corporate Rules, etc.) and reference where the user can obtain a copy.

Per Article 13(2)(a):

• You must disclose the retention period or, where this is not possible, the criteria used to determine the period.

Per Article 13(2)(b) and Article 15:

• You must disclose the data-subject rights — access, rectification, erasure, restriction, portability, objection — and how to exercise them.

Step-by-step: building a defensible list

1. Inventory every domain your code hits in production. Tools like tcpdump, browser DevTools, or your hosting provider’s egress log will surface the actual list.
2. For each domain, find the vendor and the legal entity. A vendor often has multiple legal entities (Stripe Payments Europe, Ltd. and Stripe, Inc., for example). Both should appear if both touch the data.
3. For each vendor, locate the DPA you accepted. Most are linked from the vendor’s terms or legal page. If you can’t find one, you may not have a processor relationship — flag for review.
4. Identify the legal basis you rely on for sharing data with each processor. Art. 6 lays out the bases; for processors acting on your instructions, contractual necessity or legitimate interest are the most common, but the right answer depends on your facts.
5. Identify the international-transfer mechanism for any non-EEA processor. Standard Contractual Clauses (the EU Commission 2021/914 module) are the most common; some US providers also offer the EU-US Data Privacy Framework certification.
6. Compile the list as a section of your privacy policy. Keep it updated when you add or remove a vendor.

Common mistakes

• Listing categories only. “Analytics providers” is technically allowed by Art. 13, but it makes it hard for a user to exercise their Art. 15 rights. Most counsel-reviewed policies name the vendor.
• Missing the AI provider. OpenAI / Anthropic typically process user input; declare them.
• Forgetting the CDN. Cloudflare and Vercel see IPs and request metadata; they are processors even if you “never thought of them” as data processors.
• Stale list. When you switch a vendor, update the list. The regulation expects current information.

FAQ

Do I need a separate processor list page? Not strictly — most indie policies include the list as a section of the main privacy policy. Some larger apps publish a separate “/subprocessors” page that they version.

Does GDPR apply if my app has no EU users yet? GDPR follows the data subject, not the company. If anyone from the EU ever signs up, the regulation applies to their data. Most indie apps build to GDPR from the start because retrofitting later is harder.

How often should I update the list? At minimum whenever you add or remove a vendor. Some teams add a “last reviewed” date at the bottom of the policy.

Related reading

• What disclosures Stripe, PostHog, Supabase, and OpenAI typically require
• CCPA ‘Do Not Sell or Share’ for SaaS that uses ad-tech retargeting
• Check your stack’s disclosure matrix