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 it inferred without adding facts, what remains unknown, 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 a checklist can 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 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 summarise it here: 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 promptly to the responsible team or a qualified privacy adviser, with guidance from the relevant authority. The Dutch authority is the Autoriteit Persoonsgegevens. That does not make the AP competent for every user or suspend an applicable duty while seeking advice. The retained context is EU and Dutch law, not UK law because the page is English. 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 this skill is not qualified 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 a sourced legal summary with its limits 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 a pitfall in GDPR text that an AI model can repeat. 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. Specific statutory periods can come from other laws, including the seven-year rule for defined records under article 52 of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen). It is not a universal deletion deadline. A purpose-based retention policy also needs justification. The skill distinguishes law, reported practice and policy questions; it neither invents nor approves a period.

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 an authored illustration of the intended self-check, not measured model behaviour: 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 stated, inferred without adding facts or remains unknown. It sets a status code per part. It adds a sourced summary of the GDPR, with the article, and what it specifically does not say. It makes the immediate next step concrete. The limits remain section 7, even if you ask to omit them, followed by the self-check in section 8.

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 of the seven section codes are 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 this skill does not assess legal risk; the responsible controller or incident team still performs its own required assessment. 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 includes eight, 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 Article 10 data on criminal convictions and offences. 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. Paragraph 9 includes written electronic form; the actual relationship determines the role, not the supplier name. 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 data subjects without undue delay where high risk is likely, subject to its exceptions. The controller remains responsible; a processor informs its controller without undue delay. Do not wait for an adviser if that would delay an applicable duty. 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 specific statutory periods can come from other laws, including article 52 of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen). Seven years is not a universal deletion deadline; purposes and a justified policy also matter. And cookies in the Netherlands are governed by article 11.7a of the Dutch Telecommunications Act (Telecommunicatiewet), with the GDPR also applying where personal data is processed. 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 promptly contact the responsible incident team or qualified adviser and check the competent authority's guidance, without postponing applicable duties, 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 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.