The GDPR checklist skill for Claude

The problem the skill solves is not that business owners do not know the GDPR. It is that they do not know what they process. Ask the owner of an installation company which personal data moves through their business and the answer is usually: customer names and addresses, I think. Push further and it becomes twenty: the photos of meter cupboards in a WhatsApp group, the schedule on the foreman's phone, the job applications in a mail folder, the exports in the Downloads folder of a laptop nobody uses any more. Without that overview every checklist is a guessing game, so this skill starts not with the law but with the inventory.

What you get back is deliberately not a document full of ticks. It is an overview of seven blocks in which each part states what you said yourself, what the skill inferred from it, and which status code belongs to it. Five codes: in order, incomplete, missing, unknown and to lawyer. Unknown is a valid outcome and the skill never fills it in to avoid it. That sounds like a detail, but it is exactly where most GDPR tools go wrong: they tick a box because something was filled in, not because something was actually arranged.

The skill is useful for anyone with a business and no privacy department. The sole trader who gets a client on the phone asking if they are GDPR compliant. The fifteen-person SME that has had a webshop for two years and never thought about everything sitting in it. The agency that processes data belonging to its clients' clients and does not know whether it is a processor or a controller. It belongs to the skill library NL that we make available for free through the AI and automation service, with no account and no sales email afterwards.

One thing is stated immediately in the file, and we take it over here word for word: this is not legal advice and the skill never says whether something is lawful. In an ongoing incident, a letter from the Dutch Data Protection Authority (Autoriteit Persoonsgegevens), a complaint from a client or employee, or a dispute, it stops the checklist and refers you to a privacy lawyer and to the Autoriteit Persoonsgegevens. That is not in the small print at the bottom, it is stated upfront among the cases where the skill should not start, and it appears in every output it produces.

The ticks are about documents, not about data. A privacy notice, a cookie notice and a processing agreement are the visible side. The invisible side is the export file with customer data that someone emailed to their private address last year. This skill therefore starts at blocks 1 to 4, at the data itself, and only afterwards at the paperwork.

The checklist fills itself in. A GDPR overview for a webshop looks like every other GDPR overview for a webshop, and that is exactly why a language model is dangerous here: it knows what usually goes there and fills it in. The file calls this the fastest mistake to make, and the self-check has its own control for it. Anything the user did not say comes out or becomes a question.

It produces a verdict nobody is allowed to give. The moment a tool says you comply, it has turned into a legal verdict. That is refused in both directions: it does not say something is allowed, and it does not say something is wrong either. It describes what you said, sets what the law literally says next to it, and turns the rest into a question for a lawyer. Reassurance is a verdict too, and the self-check removes that just as hard.

It states retention periods that come from nowhere. This is the most common mistake in GDPR text on the internet, and AI models happily copy it. The GDPR itself names almost no concrete retention periods: Article 5(1)(e) only says you do not keep data longer than necessary for the purpose. Periods you do come across come from other laws, such as the seven-year tax retention duty under article 52 of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen). It is therefore not allowed to fill in a period itself, not a single one.

No first step comes out of it. Fifty recommendations are about as useful as zero. So it produces one immediate next step, with who does it and what counts as done when it is finished, and puts the rest in a list of questions for the lawyer. That way you know what you solve yourself and what you are paying for. That saves on the lawyer's bill, because the searching is yours to do and the judging is theirs.

In diff form, with the correction the self-check makes in almost every first draft: the verdict out, the description with the question in.

Then comes the core: nine fixed actions. First it establishes whether this is an inventory or an incident, because with something happening right now the checklist stops.

It draws out the context. It works through the seven blocks with three to five questions per block, in small portions rather than a list of thirty lines. For every answer it notes whether it was said by the user or inferred by itself. It sets a status code per part. It adds what the GDPR literally says, with the article, and what it specifically does not say. It makes the immediate next step concrete. It runs the self-check pass. And it closes with the limits block, which never lapses, even if you ask it to.

Before the blocks get filled in the skill runs through a mandatory input checklist of eight points: what the business does and how many people work there, who the data subjects are, which types of data are involved, which systems and tools are used including loose phones and paper folders, which parties process on its instructions, whether any data ends up outside the European Economic Area, what documents already exist, and whether anything has ever gone wrong. On that last point sits the referral: if it is happening now, the checklist does not go ahead. One line in that checklist stands out and is typical for this subject: do not ask for real personal data. Categories are enough, and a supplied customer list is not used by the skill.

The output has a fixed structure of eight blocks. A header with the business, the date and how many answers are marked unknown. The seven blocks with the source and the status code per line. What is in order, and that block is allowed to be empty. What is missing or unknown, ordered by how many other answers depend on it and explicitly not by risk, because assessing risk is legal work. The immediate next step. Five to ten questions for your lawyer, worded exactly as given, with the facts from the conversation attached. The limit of this overview. And finally a block stating what the self-check adjusted.

That block with questions for the lawyer is where the skill earns its keep, even though it costs nothing. In the example in the file it produces seven, including: is our accountancy firm a processor or an independent controller for the payroll administration, and do we fall under the registration duty of article 30 or under the exemption in paragraph 5. Those are questions a lawyer can act on immediately, and where a business owner gets stuck alone because the answer depends on the circumstances.

The file also contains two fully worked examples with input and full output, a chapter of writing rules, the eleven things the skill never does, a list of moments when you need a lawyer or the Autoriteit Persoonsgegevens, and a source list with four main sources plus two laws that come up alongside the GDPR. Want to learn to set up this kind of instruction file yourself? The approach is in writing a SKILL.md NL.

The legal bases sit in article 6(1). Six of them: consent, performance of a contract, legal obligation, vital interest, public interest or official authority, and legitimate interest. What is not in there is which basis fits your newsletter, your camera surveillance or your customer file. Which basis you think you are using therefore gets noted, and not confirmed. With legitimate interest the part goes to the lawyer by default, because that is the basis with the most real-world debate around it.

The record of processing activities sits in article 30, with an exemption in paragraph 5. That exemption applies to organisations with fewer than 250 employees, unless the processing could pose a risk to the rights and freedoms of data subjects, the processing is not occasional, or it involves special categories of personal data or data on criminal convictions. Those exceptions always get added, with no conclusion on whether your business falls under it. That is exactly the kind of question you take to the lawyer, and the overview you build with the skill contains most of what they will then want to know.

The processing agreement sits in article 28. The relationship with a processor is set out in a contract or another legal act, and the article lists what has to be arranged in it. What is not in there is whether a specific party is a processor in your case. For an accountancy firm that answer is not always the same, and the skill does not take a side on it.

The data breach notification sits in article 33. A breach is reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely that the breach poses a risk to the rights and freedoms of individuals. Paragraph 5 of that same article says you document every breach, including the ones not reported. Article 34 covers informing the data subjects themselves in the event of a likely high risk. Those words likely and risk are exactly why the skill does not make that call: that is a legal judgement about a specific situation.

Two things that often get mixed up, and that the file keeps apart. Retention periods rarely come from the GDPR: article 5(1)(e) only names the principle of storage limitation, and concrete periods come from other laws such as the seven-year tax retention duty in article 52 of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen). And cookies in the Netherlands are governed by article 11.7a of the Dutch Telecommunications Act (Telecommunicatiewet), not by the GDPR. It can therefore name cookies as a separate subject, but it does not assess a cookie banner. Anyone who wants their website checked on that point is better off with a WordPress specialist who knows the technique behind it, and after that still with a lawyer for the verdict.

After that, using it is simple: say what your business does, how many people work there and which tools you use. It asks itself for whatever is missing, block by block, and it does not ask for real customer data. How long that conversation takes depends mostly on how much you have to hand: as soon as you have to start searching for where things sit, it gets longer. That searching is, by the way, not wasted time but the point of the exercise. If you get stuck while installing, the full step-by-step plan per environment is in installing Claude skills NL, and the broader explanation of working with AI is in the knowledge base.

There are also situations where you are better off leaving it aside, and the file is brief about that. Not for an incident happening right now: then you call a lawyer and check the website of the Autoriteit Persoonsgegevens, and the skill says that too, first. Not for a letter from the regulator or a complaint from a client or employee. Not to get confirmation that something is allowed. And not if you are hoping for a document you can send a client as proof it is arranged, because it does not produce that document and does not make that statement.

One more honest limit, and it applies to every skill: this is a language model with an instruction, not a system that looks inside your business. It does not see your systems, cannot check whether what you say is correct, and does not know what sits in your mailbox. Everything it produces rests on your own answers. That is not a shortcoming of this file but the nature of the tool, so the skill says it again in every overview.

What does work well is combining it with a few other skills from the same library. The Pre-Mortem Analyst NL lets you think ahead about what goes wrong before it goes wrong, and that is exactly the conversation that belongs with block 7. The Red Team Analyst attacks your own assumptions, for instance the assumption that only you can get into the mailbox. And the MECE Problem Structure Coach is the completeness check for anyone who wants to be sure no category of data has stayed out of sight.

If you then put AI to work on tasks involving personal data, you want to know in advance what happens with it. What we agree and what we do not promise is in the AI policy, and what we make public about our own use of AI is in the AI transparency NL page. If you want your team to work with AI without data ending up somewhere it should not, that belongs with the AI training NL.