Sign In Get Started
Compliance Guide

You must verify who they are.
You must also hold less.

Both are data protection obligations, and they pull in opposite directions. Most platforms resolve the tension by collecting passports and hoping the encryption holds. There is a better answer, but it starts with being honest about what a verification provider can and cannot take off your hands.

ProntoID  ·  Brooks & Keitt Sàrl · · 13 min read

If you run a platform where people upload content of themselves or others, you are under pressure from two directions at once. Age verification rules, payment scheme requirements and federal record-keeping law all want you to establish who someone is. Data protection law wants you to hold as little about them as possible.

These are not in genuine conflict, but the obvious implementation puts them there. The obvious implementation is: collect a passport scan, store it, encrypt it, and hope. That satisfies the first pressure and fails the second, and it leaves you holding the single most damaging category of data you could possibly hold.

The tension, stated properly

Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary for the purpose. Now consider what age verification actually needs to establish: a single binary fact. Is this person over 18.

Collecting a full identity document — name, date of birth, document number, nationality, photograph, machine-readable zone — and retaining it in order to answer one yes-or-no question is difficult to describe as limited to what is necessary. The document has to be examined by someone. It does not follow that it has to be kept by you.

That distinction is the whole design. Separate the examination from the result. One party looks at the document, because someone has to. The platform receives the conclusion and a reference. Both obligations are then satisfiable at once, and the heaviest data sits with the party whose entire function is holding it safely.

There is a second layer to this on adult platforms, and it is worth naming. Biometric data processed to identify someone is Article 9 special category data. So is data concerning a person's sex life. A platform verifying performers is therefore processing two Article 9 categories at once, about the same people, at scale. That is close to the highest-risk profile in commercial data protection, and it is why the answer cannot be a slightly better filing cabinet.

What genuinely improves

Not everything. But these are real, and they are the reasons worth buying for.

Your Article 9 exposure shrinks

§ 5(1)(c), 32

Identity documents and biometric templates are the heaviest data you could hold. If they never enter your systems, an Article 9 breach of that data is not yours to notify, remediate or explain. You hold a verification result and a reference; we hold the document.

Storage limitation becomes a calculation

§ 5(1)(e)

Retention stops being a policy nobody applies and becomes a computed date that recalculates when a record is amended. Article 5(1)(e) asks you to keep data no longer than necessary; that is much easier to evidence when the period is derived rather than remembered.

You can demonstrate consent, not just assert it

§ 7(1)

Article 7(1) requires a controller relying on consent to be able to demonstrate it. A versioned statement, bound to a verified identity, timestamped, and hashed over a stored canonical payload is a demonstration. A checkbox in a database table is not.

Breach scope narrows

§ 33, 34

Articles 33 and 34 turn on what was compromised. A platform that holds tokens rather than passports has a materially smaller notification problem and a materially smaller conversation with a regulator.

Data protection by design has something to point at

§ 25

Article 25 is hard to evidence with intentions. A documented flow where the document is examined by the party that needs it and the platform receives only the conclusion is the kind of thing an assessment can actually describe.

Rights requests have a route

§ 12, 15–22

A named channel, a written procedure, defined timescales, and a register. Article 12 gives you a month; the difficulty is almost never the deadline, it is not having decided in advance who does what.

The third one is the least appreciated and probably the most valuable in a dispute. Article 7(1) does not ask whether someone consented. It asks whether you can demonstrate that they did. Those are different questions, and most platforms can answer the first and not the second. A boolean column in a database, with no record of what wording was on screen, no binding to a verified identity and no protection against later alteration, demonstrates very little.

We are a controller, not your processor

This is the part that surprises people, so we lead with it rather than letting it emerge in a diligence call.

Most vendors in this space present as processors: they process on your instructions, you sign an Article 28 agreement, and the relationship is tidy. ProntoID does not fit that description and we will not claim it. We determine the retention period. We hold records in our own name. We decide how a recovery or disclosure request is handled. We answer to the individual directly. That is controller behaviour, and describing it as processing would be a convenient fiction that collapses the moment anyone examines it.

The practical consequences are worth understanding before you sign anything:

  • The arrangement between us is controller-to-controller, not an Article 28 processing agreement.
  • The collection stage may amount to joint controllership under Article 26 — you decide who is asked to verify and why, we decide the format and retention. That needs assessing and papering, with the essence made available to data subjects.
  • We owe Article 13 and 14 notices directly to the people we verify, rather than relying on yours.
  • Individuals can exercise their rights against us directly, and we will not route them back to you as a way of avoiding them.

This is a feature, not a concession. Independence is precisely what makes a consent record evidential rather than self-serving. A record held by a party acting on your instructions is, in substance, your own record. A record held by an independent controller with its own obligations to the individual is something else entirely — and that difference is the whole point when somebody disputes what they agreed to.

The instinct is to build everything on consent. It feels respectful and it looks clean in a privacy notice. For a record you need to keep for years, it is a trap.

Explicit consent under Article 9(2)(a) can be withdrawn at any time under Article 7(3), and withdrawal must be as easy as giving it. So an evidential record whose only basis is consent can be dismantled by the person with the strongest motive to dismantle it, at exactly the moment it matters. That is not a theoretical risk; it is the predictable case.

The more durable construction is Article 6(1)(f) legitimate interests together with Article 9(2)(f) — processing necessary for the establishment, exercise or defence of legal claims. That is what an evidential record genuinely is, and it does not evaporate on request.

Two things follow. The basis must be documented that way from the start, because a lawful basis cannot be swapped later to rescue a decision. And any consent you do rely on for genuinely optional things must be separately given, separately refusable, and not bundled into a document someone has to sign to use your service — Article 7(4) is unforgiving about that.

When someone asks you to delete everything

You will get these requests, and you may lawfully refuse in part. Article 17(3) permits retention where processing is necessary for compliance with a legal obligation, or for the establishment, exercise or defence of legal claims. A record evidencing what someone authorised, held to defend a claim about that authorisation, sits squarely inside the second.

What you must not do is comply quietly in part. Deleting what is easy, keeping what you need, and saying nothing is itself a breach. Tell them what is retained, on which exception, until when, and that they can complain to a supervisory authority. The refusal is defensible. Concealing it is not.

The related point: withdrawal of authorisation and erasure of the record are different acts. Someone can withdraw permission to publish — and publication should stop — while the sealed record of what they previously authorised is retained as evidence of the position at the time. Explaining that distinction to people before they sign is far easier than explaining it afterwards.

The automated decision problem nobody plans for

Article 22 gives people a right not to be subject to decisions based solely on automated processing which produce legal effects or similarly significantly affect them.

Now consider a creator whose income comes from your platform, whose document scan fails an automated check because of glare on the laminate, and who is refused access with no route of appeal. Whether that clears the Article 22 bar is genuinely arguable — but it is arguable in a direction you do not want to be arguing in.

The fix is cheap and worth doing regardless: provide a human review route for failed verifications, make it easy to find, and say so in your privacy notice. It improves the product as well as the compliance position, because automated verification does fail on legitimate documents and those users are worth keeping.

What stays yours whatever you buy

No vendor can carry these, and any vendor implying otherwise is selling you a problem for later.

Your lawful basis

Nobody can supply this for you. It has to be identified, documented and stated in your notice before processing starts, not reconstructed afterwards.

Your DPIA

Article 35(3)(b) makes it mandatory for large-scale Article 9 processing. Using a vendor changes what goes in it, not whether you need one.

Your Article 30 records

A record of processing activities covering everything you do, not just the part you outsourced.

Your privacy notice

Including telling people that a separate controller verifies their identity, and what that controller does with it.

Your Article 27 representative

If you are established outside the EU or UK and process at scale, you need your own. Ours does not cover you.

Everything else you hold

Content, messages, payment data, analytics, logs. The identity layer is one flow among many.

Transfers, stated plainly

Brooks & Keitt Sàrl is established in Switzerland and the processing infrastructure is in AWS us-east-1. For EU and UK personal data that is a Chapter V question, and for Article 9 data we do not think an adequacy mechanism alone is the right place to stand. Standard contractual clauses with a documented transfer impact assessment is the more defensible position. Ask us for the documentation during onboarding — and ask every other vendor the same question, because the answer is revealing.

A practical checklist

  1. 1 Decide your lawful basis for the retained record before you build anything — and think hard before choosing consent.
  2. 2 Write the DPIA. If the flows are documented it is a day of work, not a month.
  3. 3 Establish whether your relationship with any identity provider is controller-to-controller or joint, and paper it accordingly.
  4. 4 Check what your provider actually stores, and what crosses back to you. If they hand you the document image, ask why.
  5. 5 Make retention a computed value rather than a policy statement.
  6. 6 Give rights requests a named destination and a written procedure, including who assesses identity before you act.
  7. 7 Provide a human review route for automated verification failures, and say so in your notice.
  8. 8 Confirm the transfer basis for any non-EEA processing, and ask to see the transfer impact assessment rather than assuming one exists.
  9. 9 Decide in advance what you will refuse to erase and on which Article 17(3) exception, so the answer is consistent.
  10. 10 Appoint your own Article 27 representative if you need one.

There is a working checklist version of all of this, with separate tracks for platforms, photographers and studios.

If federal record-keeping is also in scope for you, the two regimes interact in ways worth reading about together — our guide to § 2257 for platforms covers the retention side, and buying content from another producer covers the case where the personal data reaching you came from someone else entirely.

This article is general information, not legal advice. ProntoID and Brooks & Keitt Sàrl are not a law firm. Data protection analysis turns on facts specific to your platform, your users and your establishment, and the position differs between the EU, the UK and Switzerland. Take qualified advice before relying on anything here.

Frequently Asked Questions

What your DPO
will want to know

Is ProntoID our data processor?

No, and this surprises people. ProntoID is an independent controller of the identity and release records it holds. We decide the retention period, we hold the records in our own name, we answer to the individual directly, and we determine how a recovery or disclosure request is handled. That is controller behaviour, and calling it processing would be a fiction. It means the arrangement between us is controller-to-controller rather than an Article 28 processing agreement, and the collection stage may need an Article 26 assessment.

Does using ProntoID make our platform GDPR compliant?

No. It removes one of the heaviest categories of data from your systems and gives you evidence you would struggle to construct yourself. It does not give you a lawful basis, a record of processing under Article 30, a data protection impact assessment under Article 35, a privacy notice, or a retention schedule for everything else you hold. Those remain yours.

Do we still need a DPIA?

Almost certainly. Article 35(3)(b) makes an assessment mandatory for large-scale processing of Article 9 data, and identity verification for adult content platforms typically involves both biometric data and data concerning sex life. Engaging a vendor does not remove the obligation — if anything the assessment becomes easier to write, because the flows are documented and the retention is defined.

Why is age verification a data protection problem at all?

Because the obvious implementation is disproportionate. Collecting a full identity document to establish a single binary fact — that someone is over 18 — sits awkwardly with Article 5(1)(c), which requires data to be adequate, relevant and limited to what is necessary. The answer is not to skip verification but to make sure the document is examined by someone who needs it and that the platform receives only the conclusion.

Can we rely on consent as our lawful basis?

For the retained record, we would advise against it. Explicit consent under Article 9(2)(a) is withdrawable at any time under Article 7(3), and an evidential record you need to keep for years cannot rest on a basis the subject can remove tomorrow. Article 6(1)(f) legitimate interests together with Article 9(2)(f) — establishment, exercise or defence of legal claims — is the more durable construction, and it needs documenting from the start rather than retrofitted.

What happens when someone asks us to delete everything?

You assess it, and you may lawfully refuse in part. Article 17(3) permits retention where it is necessary for compliance with a legal obligation or for the establishment, exercise or defence of legal claims. What you must not do is comply silently in part: tell them what is being kept, on which exception, until when, and that they can complain to a supervisory authority. Silent partial compliance is itself a breach.

If a verification fails automatically, is that an Article 22 decision?

It is a fair question and the answer is not settled. Article 22 gives a right not to be subject to a decision based solely on automated processing which produces legal effects or similarly significantly affects someone. An automated check that blocks a creator from a platform they earn a living on may well clear that bar. The practical response is cheap: provide a human review route for failed verifications and say so in your notice. We support manual review for exactly this reason.

Where is the data held, and what covers the transfer?

Brooks & Keitt Sàrl is Swiss, and the processing infrastructure is in AWS us-east-1. That is a Chapter V question for EU and UK data, and for Article 9 data we would not want to rest on an adequacy mechanism alone — standard contractual clauses with a documented transfer impact assessment is the more defensible position. We will share our transfer documentation during onboarding rather than asking you to take it on trust.

Someone uploads a third party's ID. Whose problem is that?

Both of ours, in different ways. Where personal data is obtained other than from the individual, Article 14 generally requires them to be informed, with an exception at Article 14(5)(b) for disproportionate effort. Our upload flows record the uploader's contact position with that person precisely so the assessment rests on something written down at the time rather than reconstructed afterwards. We handle notification where contact is possible and document the position where it is not.

Bring your DPO to the call

We would rather answer the controller question, the transfer question and the retention question up front than have them surface halfway through your diligence.

Talk to us § 2257 for platforms

Brooks & Keitt Sàrl  ·  Place du Midi 30, 1950 Sion, Switzerland