GDPR Article 30 ROPA for AI-Built SaaS: The Record Most Founders Skip

Most guides treat Article 30 as a filing job. Grab a template, fill in nine columns, tick the box. That framing is why so few small teams have one.

The real problem is a software problem. The record asks you to say what personal data your product holds. You cannot answer that from memory when an AI tool wrote the schema. So the first step is not a template. It is reading your own tables.

What Article 30 actually asks for

Article 30 asks you to keep a written record of what you do with personal data. There is no portal. There is no filing date. Article 30(4) says you hand the record to the supervisory authority on request. That means your national regulator. The record sits with you until they ask.

That is why it gets skipped. Nothing chases you for it. Then one day something does.

Article 30(3) says the record must be in writing, and adds that electronic form counts. A spreadsheet is fine. A page in your wiki is fine. Format is not the point. Being able to hand it over in a day is the point.

A controller record has to hold seven things:

• Your name and contact details. Your data protection officer, if you have one.
• Why you hold the data.
• The types of people, and the types of data.
• Who you share it with, including anyone outside the EU.
• Any transfer to another country, and the safeguard you lean on.
• Where possible, how long you keep each type of data.
• Where possible, a short note on how you keep it safe.

Seven columns. That is the whole document.

The 250-staff rule almost nobody gets

Here is the line that sends most founders back to work. Article 30(5) says the duty does not apply to a firm with fewer than 250 staff.

Now read the rest of the sentence. The let-off drops away unless all three of these hold. The work is unlikely to put people's rights at risk. The work is occasional. And it touches no special category data. No criminal offence data either.

Those three are joined by "or", not by "and". The Article 29 Working Party said so in a paper on this clause. The European Data Protection Board backed it. Any one of the three, on its own, brings the duty back.

So the whole question turns on one word: occasional.

The same paper gives the test. Work counts as occasional only on two counts. You must not do it regularly. And it must sit outside the normal course of business. Both parts have to hold.

Now read that against a SaaS product. You store user accounts. You do it every day. It is not a side activity, it is the business. It fails both halves of the test at once.

The ICO uses an insurance firm with 100 staff to make the same point. Claims, sales and HR all get documented, because the firm does them regularly. The annual staff survey does not, because it is genuinely rare.

Swap the insurance firm for your product. Signups, billing and support are your claims, sales and HR. You are under 250 people and you still owe a record.

One more thing worth knowing, because other pages are muddy about it. The European Commission has asked to raise the limit from 250 staff to 750. As of September 2026 that change is not law. It is still being debated. The number that binds you today is 250.

And even if it does pass, it changes what is required, not what is useful. The rest of this article explains why.

You are probably a controller and a processor at once

Article 30 has two halves, and most templates only give you one.

Article 30(1) is the controller record. It covers the data where you decide the purpose: your signups, your staff, your marketing list, your support inbox.

Article 30(2) is the processor record. It covers data you hold on behalf of someone else. If your customers are businesses, and their staff or their end users live in your database, you are a processor for that data.

The processor record is shorter. It needs four things. Who you are, and who each controller is. What you do with their data. Any transfers abroad. And a short note on how you keep it safe.

There is a commercial reason to write it early. The first big deal you chase will send you two things. A data protection agreement, and a security form. Both ask what you do with their data. A processor record answers that on one page. Without it, you answer by email for three weeks.

Write the record from your schema, not from memory

This is where the job gets real. It is also the part no template can do for you.

There are two lists. What you think your app collects. What your tables really store. When you wrote the schema by hand, those lists match. When a tool wrote it for you, they drift apart quietly.

Ask an AI coding tool for a users table and you often get more than name and email. You get a column for the last login IP. A user agent string. An avatar URL that points at some other site. A metadata or JSON column that swallows whatever the signup form happened to send. Somewhere else, a raw events table keeps the full webhook payload from your payment tool. Name and part of a card number included.

None of that is a bug. It is a fair default for a generic app. But Article 30 judges your record against the table, not against what you meant. If the column holds it, the record has to say so.

So build the list from the database:

1. List every table with a column that can point at a person. Email, phone, IP, device id, or a user id that maps to one.
2. Open every JSON or metadata column and read one real row. Read it. Do not guess at it.
3. Check the tables you did not design. The auth schema. Audit, event and log tables. Queue and webhook tables too.
4. Write the purpose next to each group. If nobody can say why a column is there, that is a finding, not a layout problem.

An IP address counts as personal data when you can tie it to a person. In a logged-in app you usually can. The row sits right next to a user id.

This step is also what makes the rest of GDPR cheaper. The same list feeds your DSAR checklist when someone asks for a copy of their data, and your erasure runbook when they ask you to delete it. Our data mapping guide covers the wider version of the same hunt.

Your list of vendors is in your environment file

Article 30(1)(d) asks who you share the data with. Founders stall here, because the field sounds legal.

It is not. Open your environment file. Nearly every key in it is a company that gets some of your users' data.

The auth host. The database host. The mail sender. The error tracker. The analytics tool. The payment provider. The support widget. The file storage bucket.

Three columns fall straight out of that list:

• Who receives it goes in the recipients column.
• Where their servers sit goes in the transfers column, along with the safeguard you rely on. Our guide to international data transfers covers what that safeguard has to be.
• What you signed with them is your processor contract. If you have not checked those, start with the data protection agreements behind AI coding tools.

If a vendor lands in your record and has no signed agreement, you have just written down your own gap. That is not the job failing. That is the job working.

The two columns founders leave blank

Two fields carry the words "where possible". People read that as optional. It means something narrower. State it where you can state it.

Retention. How long do you keep each category? If the honest answer is forever, write forever. Then look at how that reads on the page. Keeping everything for ever sits badly against the rule on how long you may keep data. It is also the main reason delete requests take days rather than minutes.

Security. A general description, not a threat model. Encryption in transit and at rest. Who holds production access. Whether admin accounts have MFA. How secrets are stored. Whether row level security is switched on. Our privacy by design guide covers the version of this you build in rather than write down.

Why the record saves you in the 72 hours after a breach

This is the argument that turns a chore into insurance. It is also the one most guides miss.

Article 33 gives you 72 hours to report a data breach, where that is feasible. And Article 33(3)(a) sets out what the report has to say. It must describe the nature of the breach. Where possible, it must give the categories and rough number of people hit. It must give the categories and rough number of records hit too.

Now hold that next to Article 30(1)(c). That field asks for the categories of people, and the categories of personal data. Same two facts.

They are the same two facts. One you write down on a quiet Tuesday. The other a regulator asks for on the worst day of your year, with a clock running.

With no record, day one of a breach goes on reading your own schema to work out who was in the table. Our guide to breach notification in 72 hours walks the rest of that clock.

There is a second link worth seeing. Article 30(5) brings the duty back when your work is likely to put people's rights at risk. An impact assessment under Article 35 is triggered by a high risk. The register's bar is the lower of the two. Plenty of products clear it without ever needing a full one.

A starter record you can fill in today

Here is a controller record with four rows filled in. The wording is as plain as it can be and still do the job.

Two columns are missing from that table on purpose, because they do not fit on a screen. Those are transfers, and your note on security. Add both. Transfers only needs the country and the safeguard. Security only needs four or five lines.

If you also hold data for business customers, you need a second, shorter table. It lists each controller you act for, what you do with their data, where it goes, and how you protect it.

Keep the wording plain. Nobody is grading your prose. The record is judged on whether it is complete, current and true.

And treat it as a living document. The ICO makes that point directly. The record has to show what you are doing now, not what you did at launch. Tie the update to something you already do, like a release checklist or a monthly review.

What a scan can see, and what it cannot

Being straight about the limits matters here. This is one place where an outside view only gets you part of the way.

Our Compliance Score runs 60 automated checks against your live URL and your public documents. Two of them speak to this article. One is Data rights mechanisms (delete, export). The other is Privacy policy completeness. Together they tell you whether the outside of your product matches what a record would claim about it. The same product ships template documents. A ROPA template is one of them.

What no scan can do from the public internet is read your schema. Nobody outside your database can say which columns your users table holds. Nobody can say what sits in that JSON blob. That part takes an hour with your migration files, or a read-only look at the code.

Across the 700+ AI-built apps we have audited, the average Launch Readiness Score is 44/100. Article 30 is not one of the things that score measures. A record is paperwork, and the score measures code. But the reason the record is hard to write is the reason the score is low. In both cases, nobody has yet read what the generated code really does.

What to read next

The register is the spine of the rest of the GDPR work, so most of it connects. The wider hunt for where data lives is data mapping, and the register is what that hunt produces. When someone asks for a copy of their data you need the DSAR checklist; when they ask you to remove it you need the right to erasure runbook, and both go faster if the record already says where to look. The vendors in your recipients column are governed by your DPAs with AI coding tools. If you want the paperwork drafted rather than explained, that sits inside the Compliance Wing, and the code side of the same question is the Launch Readiness Audit. The full set of guides is in the blog index.

FAQ