Free GDPR record-of-processing template

If a customer’s security team, an investor’s due diligence checklist, or a regulator ever asks “where’s your Record of Processing Activities,” the honest answer for most vibe-coded apps is “our what?” That document is smaller and less scary than it sounds, and you can have a first draft done this afternoon.

Download the template (PDF)

What a Record of Processing Activities actually is

Article 30 of the GDPR asks organizations to keep a written record of how they process personal data. Not a policy, not a promise, a plain inventory: what data you collect, why, who else touches it, how long you keep it, and how it’s protected.

Think of it as the map a regulator, an enterprise customer’s security reviewer, or your own future self would need to answer “what happens to a user’s data after they sign up.” If you can’t answer that in five minutes today, you don’t have this document yet, and that’s exactly the gap the template below closes.

Do you actually need one?

Article 30(5) exempts organizations under 250 employees, unless the processing is not occasional, could risk someone’s rights, or includes special-category data (health, biometric, political, and similar).

In practice, almost no real app clears that bar. If people create accounts, you process data regularly, not occasionally. If you take payments, that’s data whose mishandling carries real risk. So the honest reading is: if your app has real users, keep the record. It’s an afternoon of work, and it’s the first thing a regulator or a serious enterprise customer asks for, not a hypothetical.

What’s in the template

One table per processing activity. Most small apps end up with somewhere between four and eight activities: accounts, payments, support, marketing email, analytics, and, increasingly, any place your app sends user data to a third-party AI model.

Each entry covers:

Purpose of processing. Why you collect and use this data, specifically, not “to run the app.”
Categories of data subjects and data. Who the data is about, and what fields you actually store.
Legal basis. Consent, contract, legitimate interest, or legal obligation.
Recipients and processors. Every third party that touches the data: your database host, your email provider, your payment processor, your analytics tool.
Third-country transfers. Whether any of those processors store or access data outside the EU/UK, and under what transfer mechanism.
Retention period. How long you keep it, and what triggers deletion.
Security measures. Encryption, access controls, backups, who holds admin access.

That’s the whole document. No legal boilerplate, no fifteen-page policy nobody reads.

How to fill it out without losing a day

Work backward from your codebase, not forward from a legal textbook. Open your app and list every place a user’s data leaves your own database: your email sender, your payment processor, your error-monitoring tool, your analytics, and any AI API you call with user content. Each one is a “recipient” in the record. If you’re not sure what your app actually sends where, our free production audit checks exactly this as part of a broader review.

For the AI-specific row: if any feature sends user-submitted text, images, or data to a third-party model provider, that’s a processing activity of its own. Note which provider, whether it trains on your data by default (check the settings, most don’t for paid API tiers, but verify), and where its servers are.

Keep it current, not perfect

A record from a year ago that no longer matches what your app does is worse than an honest, current, slightly rough one. Set a recurring reminder, every quarter is reasonable for a small team, to open the document and check it still matches reality. The “last reviewed” field on the template exists so you can prove you actually do this, not just that you did it once.

If a real access request lands in your inbox next, see how to handle a GDPR data subject access request for the response process. For the hosting side of GDPR, EU data residency for AI app builders covers where your data actually lives.

Or, we do it for you

Compliance paperwork is one piece of a much bigger production-readiness picture. If you’d rather have someone map your app’s real data flows, flag what’s missing, and hand you a fixed list of what to fix, get a free production audit.

FAQ

Is this legal advice?

No. It’s a starting template built from the plain requirements of Article 30. For a specific compliance question, especially anything involving special-category data or a regulator inquiry, talk to a lawyer who knows your jurisdiction.

My app is tiny, just me and a few hundred users. Do I still need this?

Probably yes, if you handle accounts or payments. The size exemption is about occasional, low-risk processing, not about company size alone. A small app processing user accounts every day doesn’t qualify as occasional.

What’s the difference between this and a privacy policy?

A privacy policy is what you tell users, in plain language, about how you use their data. A Record of Processing Activities is your own internal, detailed inventory, mostly for regulators and auditors. Most of a privacy policy should be derivable from a well-kept record.

How often should I update it?

Whenever you add a new third-party tool, a new type of data collection, or a new AI feature that sends user data outward. Quarterly is a reasonable minimum check even if nothing obviously changed, since it’s easy to add a new analytics snippet or API integration and forget it belongs in the record too.