GDPR-compliant CAPTCHA checklist for 2026

Adding a CAPTCHA is a data-processing decision. If you ship in the EU/EEA, that decision has paperwork attached. This article is the 12-point checklist we use ourselves to keep a CAPTCHA implementation GDPR-clean, the lawful-basis reasoning behind it, and the actual artifacts you’ll be asked for in a procurement review.

We’re a vendor, not a law firm. Treat this as the technical starting point your DPO or counsel will review. The text of the GDPR is the canonical reference.

What GDPR cares about in your CAPTCHA

A CAPTCHA touches three GDPR-relevant surfaces:

1. You become a data controller for the visitor data your CAPTCHA collects. The CAPTCHA vendor is your processor (or sometimes a joint controller, in which case alarm bells should ring loudly).
2. The CAPTCHA loads from a third-party origin (typically), which means the visitor’s browser hands data to the vendor whether or not your verification logic does. That’s processing in its own right.
3. The CAPTCHA may set persistent client-side identifiers (cookies, localStorage). Under the ePrivacy Directive, that requires consent unless the storage is “strictly necessary.”

The good news: a well-designed CAPTCHA can be configured to ride almost entirely on the “legitimate interest” lawful basis, with no consent banner row, and minimal sub-processor impact. The bad news: most CAPTCHAs aren’t configured that way out of the box.

Lawful basis for the processing

Article 6(1)(f) — “legitimate interest” — is the right basis for CAPTCHA processing in almost all cases. Recital 49 explicitly recognizes “the security of network and information systems” as a recognized legitimate interest. The three-part test:

• Purpose. Preventing automated abuse (spam, credential stuffing, free-tier farming, card testing). Easy to articulate.
• Necessity. The processing must be necessary for the purpose. A CAPTCHA that collects mouse-path biometrics for purposes beyond verification (e.g. cross-site identity building for ad targeting) fails this test.
• Balancing. The legitimate interest must not be overridden by the rights of the data subject. A minimally-invasive CAPTCHA passes; a CAPTCHA that builds a cross-site behavioral profile fails for many regulators.

The implication: the more your CAPTCHA tracks, the harder legitimate-interest gets. A CAPTCHA that genuinely doesn’t track outside the verification surface — see privacy-first CAPTCHAs explained — has the cleanest balancing test by a wide margin.

The 12-point checklist

Walk this for whatever CAPTCHA you ship. Items 1-4 are non-negotiable for any production GDPR posture; items 5-12 are the ones that will come up in procurement.

1. You have a written DPA with the CAPTCHA vendor. Article 28 is non-optional for any processor relationship. The DPA must cover SCCs for any cross-border transfer.
2. The vendor is on your sub-processor list. And on the sub-processor list of any of your customers who you’re a processor for. This is the single most-missed item.
3. Your privacy policy names the CAPTCHA vendor. Article 13 transparency. Visitors must be able to know who processes their data.
4. You have documented a lawful basis for the processing in your Records of Processing Activities (Article 30). Usually legitimate interest; rarely consent.
5. Visitor data is retained for the minimum necessary period. 24 hours for IP-based rate limiting is defensible; 30 days is hard to defend; 12 months is not defensible.
6. The vendor publishes a sub-sub-processor list. And you can subscribe to a feed for changes. Article 28(2) gives you the right to object to additions.
7. Cross-border transfer mechanism is documented. Either an adequacy decision (e.g. EU-US Data Privacy Framework) or SCCs in the DPA. Schrems II made this load-bearing.
8. Breach notification timeline is in the DPA. The vendor must commit to notifying you within 72 hours of confirming a personal-data breach so you can meet your own Article 33 obligation downstream.
9. Data subject rights flow downstream. When a visitor exercises Article 15-22 rights with you, the vendor must assist. The DPA should specify how (typically via a documented support channel and an SLA).
10. The CAPTCHA does not use storage that requires ePrivacy consent. No cookies set on the customer domain, no localStorage entries, no fingerprint-derived identifiers. If it does, you need a consent banner row.
11. You have a deletion mechanism for end-of-relationship. When you off-board the vendor, the DPA should specify how remaining data is deleted within 30 days.
12. The vendor has a published data-residency policy. For EU customers, a primary EU region is increasingly the procurement floor. For high-trust customers, contractually guaranteed EU-only flows are the next step.

If your current CAPTCHA fails three or more of these, you have a compliance gap to close. If it fails 1, 3, or 7, you have a compliance bug to fix this quarter.

The actual paperwork

Procurement reviews ask for specific artifacts. Here’s the list, in roughly the order it’ll be asked for:

1. The DPA

A signed Data Processing Agreement. Must include the Article 28 clauses, SCCs annexes, sub-processor list, security measures appendix, breach-notification commitment, audit rights, and return/deletion at termination. Ours is available as a click-through to all paying customers and by reference in the Terms of Service for free-tier accounts.

2. The sub-processor list

Public, versioned, with a subscribe-able change feed. Lists every vendor that touches end-user data, what data they touch, and where it’s stored. Customers can object to new sub-processors before they take effect.

3. The Records of Processing (Article 30)

Your internal RoPA (you maintain this, not the vendor). Must list the CAPTCHA vendor, the categories of data processed, the purpose, the lawful basis, retention, and any cross-border transfers.

4. The Transfer Impact Assessment (TIA)

Required since Schrems II for any transfer to a third country without an adequacy decision. The TIA is your assessment that the SCCs provide adequate protection in light of the destination country’s law. The vendor should provide the inputs (data categories, transfer mechanism, security controls); you make the assessment.

5. The security measures appendix

Annex II of the DPA. Lists technical and organizational measures: encryption at rest, encryption in transit, access controls, logging, incident response. Most vendors provide a boilerplate; verify it matches reality.

6. The privacy policy update

Your own. Must name the vendor and explain what data they process. One paragraph; non-negotiable.

Playtcha’s GDPR posture as a worked example

Here’s how Playtcha maps to the checklist, item by item, so you have a concrete reference for what “clean” looks like:

1. DPA available. Template published at playtcha.com/legal/dpa; signed copies available on request.
2. Sub-processor list. Published at playtcha.com/legal/subprocessors, with prior notice for material additions.
3. Privacy policy names us. Standard.
4. Lawful basis. Article 6(1)(f) legitimate interest for verification processing; documented in our DPA and in our published compliance posture.
5. Retention. 24 hours for IPs, 24 hours after token expiry for token hashes, never persisted for game inputs. Documented in the DPA.
6. Sub-sub-processor list. Supabase, Vercel, Stripe, Resend. Same notice clause.
7. Cross-border transfers. SCCs in the DPA. EU-primary database region.
8. Breach notification. 72-hour commitment to controllers in the DPA; 24-hour operational target.
9. DSAR assistance. Requests are handled through support@playtcha.com and our public support process.
10. No ePrivacy consent required. The widget is designed to set no cookies, no localStorage, and no IndexedDB state for end-users.
11. Deletion. 30-day soft-delete on backups; 90-day hard-delete commitment in the DPA.
12. Data residency. EU-primary database region; contractually-guaranteed EU-only flows on Business+ tier (post-MVP roadmap, currently best-effort for free-tier).

Compare this posture to your current CAPTCHA vendor’s. The items where the gap is largest will tell you where the compliance work would be heaviest in a migration. For the adjacent technical implementation, see CAPTCHA with Supabase.

Common mistakes

Treating the CAPTCHA as a “functional” cookie

Some teams classify CAPTCHA cookies as “strictly necessary” to avoid the consent banner row. This is defensible for first-party cookies that are genuinely verification-only. It is not defensible for third-party cookies that the vendor uses for cross-site profiling. If the cookie is on google.com and Google uses it for ad targeting, it’s not strictly necessary.

Forgetting the sub-processor disclosure to your own customers

If you’re a B2B SaaS, your customers want to know who you send their visitors’ data to. Adding a CAPTCHA that you don’t add to your own sub-processor list is a compliance bug your customers’ DPO will eventually find.

Documenting consent as the lawful basis when you mean legitimate interest

Consent is the wrong basis for a CAPTCHA. It implies the user can refuse and still use your service, which defeats the purpose. Use legitimate interest, articulate the necessity, document the balancing test, and don’t reach for consent unless your processing genuinely requires it.

Loading the CAPTCHA before the consent banner is satisfied

For CAPTCHAs that do require consent (because they set non-essential cookies), loading the CAPTCHA on a page-cold before the consent banner has been answered is a violation. The order matters: banner first, CAPTCHA loader after consent confirmed. This is the kind of bug that gets caught in regulatory audits, not in QA.

Treating “Privacy Shield 2.0” / EU-US DPF as a permanent solution

Both prior US adequacy decisions were struck down in court. Don’t architect for a permanent adequacy decision; assume SCCs will remain the floor and a future Schrems III is plausible. That biases you toward EU-resident data flows where you can afford them.

Related reading: the upstream “do I need a CAPTCHA at all” question, in why use a CAPTCHA. The privacy-posture comparison across vendors, in reCAPTCHA alternatives. The accessibility statement that pairs with this in your compliance pack, in accessible CAPTCHA design. The bundle-weight angle that shows up in performance audits, in why your CAPTCHA shouldn’t be 250 KB.

When the checklist isn’t enough

For most B2B SaaS shipping in the EU, the 12 items above are sufficient. Two scenarios where you need more:

• Special-category data adjacent. If your service touches health, biometric, political opinion, or other Article 9 data, the CAPTCHA processing is held to stricter scrutiny because the surrounding context is. You’ll likely need a full DPIA and an explicit legal-basis review beyond the legitimate-interest default.
• Public-sector and large enterprise. Some procurement standards (EU agencies, German BSI requirements, French SecNumCloud equivalents) impose specific residency and certification requirements that no off-the-shelf CAPTCHA satisfies out of the box. In these scenarios, a self-hosted or contractually-isolated deployment is the only path; talk to vendors with an Enterprise tier that covers it.

For everyone else, the 12-point checklist is the bar. Vendors that pass it without footnotes are the ones to shortlist.

FAQ