A user emails your support address with one line. Delete everything you hold about my age check.
Three companies touched that check. You ran the gate. A vendor read the document or estimated the age from a selfie. Upstream, an operating system, a bank or a mobile operator produced a signal that started the whole thing. The user wrote to one of you, and it was almost certainly the one whose logo was on the screen.
The clock is now running. Article 12(3) of the General Data Protection Regulation (GDPR) gives you one month to answer. You can take two more months, but only if you tell the user inside the first month why you need them. Your answer has to say what you hold, what you deleted, what you kept, and the legal ground for keeping it.
Most teams cannot write that letter in a month. Not because the engineering is hard. Because nobody ever decided which company owns the answer.
Why these requests are arriving now
Until recently an age check was a moment. You ran it, you let the user in, and you kept a boolean.
Every law passed in 2026 pushes you the other way. The EU KIDS Act replaces a single threshold with account bands you have to keep current. European guidance expects re-verification on a cadence rather than once for life. New York’s draft rules under the SAFE for Kids Act propose a ten-year minimum for records of method, outcome and testing. California signed AB 1709 on 10 September 2026, which requires an age check before a platform serves addictive features and the deletion of pre-existing accounts belonging to users under 16 (Hunton).
Put those together and the shape of the problem changes. You no longer run a check. You hold age state, about a population that includes a lot of children, for years.
Age state is personal data. Personal data comes with rights attached. And filing a complaint costs a user nothing but a web form on their regulator’s site.
GDPR does not read your contract
Here is the part that surprises people. Your role is a fact about what you do, not a label you chose.
Article 4(7) defines the controller as whoever decides the purposes and means of the processing. Article 28(10) then says the quiet part out loud: a processor that decides purposes and means for some processing is treated as a controller for that processing, whatever the contract calls it.
So the question is never “what does our data processing agreement say”. It is “who decided why this data exists, for each thing we do with it”.
Five setups cover almost every real integration. The roles differ in each one.
| Setup | Who decided the purpose | Your role | Vendor role | Who answers the user |
|---|---|---|---|---|
| API check. The vendor runs the method, returns a result, keeps only what you told it to keep | You | Controller | Processor | You. The vendor has to help you, under Article 28(3)(e) |
| The vendor hosts the flow and keeps a user-held account or reusable credential | You for the gate, the vendor for the account | Controller for the gate decision | Controller for the account | Both, each for its own part |
| The vendor reuses check data to train models or to build a cross-customer fraud list | The vendor, for that reuse | Controller for your gate | Controller for the reuse | The vendor for the reuse. You still receive the complaint |
| You read an operating system, app store or carrier signal | The signal source, for the signal | Controller for what you do with it | Not involved | You for your use, the source for the signal itself |
| A wallet or double anonymity scheme attests an attribute to you | The issuer for issuance, you for the gate | Controller | Not involved | Split, and the user cannot usually tell who holds what |
Two rows in that table are where the trouble lives.
The reuse row is the one that quietly rewrites your paperwork. If your vendor improves its models on the faces your users submitted, it decided that purpose, not you. It is a controller for that. Your agreement describes it as a processor, your privacy notice probably names no reuse at all, and both documents are now wrong. Search your vendor’s terms for “improve our services”, “aggregated”, “anonymised” and “fraud network”. Anonymisation is a high bar under GDPR, so a claim that reused data is anonymous needs evidence, not an adjective.
The reusable credential row is the one teams get wrong in the opposite direction. A user-held credential is a good privacy design and we have written in favour of it, in verify once, prove everywhere. It still splits the roles. Somebody is the controller of the credential itself, and that somebody is not you.
What the user can actually ask for
A deletion request is the one that gets attention. It is rarely the one that hurts.
| Right | What the user gets | What most age gates cannot produce |
|---|---|---|
| Access, Article 15 | A copy of the data, plus the purposes, the recipients and the retention periods | The recipients. Most age gate privacy notices never name the verification vendor |
| Rectification, Article 16 | Correction of a wrong age or a wrong band | A route to fix a bad estimate that is not “make a new account” |
| Erasure, Article 17 | Deletion, unless an exception applies | A per-item answer. Teams give one yes or one no for everything |
| Portability, Article 20 | The data in a machine-readable form | Anything but a screenshot |
| Objection, Article 21 | A stop, where you relied on legitimate interests | A record of which legal basis covered which field |
| Automated decisions, Article 22 | Meaningful information, and human review | A human path. An age estimate that blocks an adult is a decision made by software about a person |
The European Data Protection Board (EDPB) set out ten principles for age assurance in Statement 1/2025, adopted on 11 February 2025. Two of them matter here. Principle 4 limits you to the age attributes strictly needed for the stated purpose. Principle 7 says users need redress and must be told how to challenge a wrong decision. That is Article 22 written as a product requirement, and it is the same argument we made about appeals and human override.
An access request is harder than a deletion request for a simple reason. Deletion can be answered with an action. Access has to be answered with a map of your own system.
The retention conflict, and the wrong way to answer it
Now the real conflict. One set of rules tells you to keep records for years. Another gives the user a right to have data erased. Both apply at once, which is the dual duty we wrote about after the ICO and Ofcom joint statement.
The tempting refusal is Article 17(3)(b): erasure does not apply where processing is necessary to comply with a legal obligation. Read the rest of that clause before you rely on it. The obligation has to come from Union or Member State law.
A New York record-keeping rule is not Union or Member State law. Neither is a Texas statute, and neither is an expectation set by Ofcom, which is a United Kingdom regulator. For a user in the United Kingdom, UK GDPR gives you the matching exception for UK duties. For a user in Germany, a New York rule is not an answer.
This is how a routine request turns into a real problem. The user complains, the regulator reads your refusal letter, and the letter cites a statute that does not bind you in that jurisdiction. You have now handed over a document that shows nobody checked.
Article 17(3)(e) is the narrower route: processing needed for the establishment, exercise or defence of legal claims. That is a stronger case when you have a live dispute, a pending investigation or an appeal in flight. It is a weak case as a general worry about a future audit. We think it works for a specific open matter and not as a blanket retention policy, and reasonable lawyers argue about exactly where that line sits.
The design answer is better than either argument. Split the record.
Keep the decision: method, outcome, threshold, confidence, policy version, timestamp, and a reference. Delete the raw material it came from: the document images, the selfie, the biometric template. The decision is what a regulator asks for, and it is what you need to prove the gate was working on a given date. The images are what turns a retention setting into a breach headline.
Be honest about the limit of that move. A decision record tied to an account is still personal data about that person. Minimisation shrinks the argument. It does not end it. If you delete the account, keep the decision under a pseudonymous reference, and write down who is able to re-link it and under what approval. An unlinkable record is a much easier letter to write than a linkable one, and that same unlinkability is the thing most double anonymity deployments claim and fail to deliver.
Four clauses your data processing agreement needs
Most age assurance agreements have one sentence on roles at the top and nothing usable after it. Four clauses do the work.
Roles, activity by activity. Not “the Vendor acts as processor”. A short table: document reading, age estimation, liveness, fraud signals, model improvement, support tickets. One role per row. If the vendor will not write “controller” against model improvement, ask what it does with the faces instead.
An assistance deadline shorter than yours. Article 28(3)(e) says the processor must help you meet data subject requests. It does not give you a number. You have one month. Put seven days in the contract, with the format of the response named, so you are not chasing an account manager in week three.
End of contract, in detail. Article 28(3)(g) requires deletion or return when the service ends. Add the list of what the vendor keeps as its own controller after that, and for how long. This is the same clause that decides whether you can actually leave, which we covered in vendor exit and portability.
Sub-processors, locations and regulator requests. Who else touches the data, in which country, with what notice period before a change. Then one line naming who answers a regulator’s information request and within what time. Every Ofcom fine in 2026 arrived with a second penalty for the information request, so this is not a small clause.
One more, for the joint control case. Article 26(2) says the essence of a joint controller arrangement must be available to the data subject. A short public summary linked from your privacy notice satisfies it. Nothing satisfies it if you never worked out that you were joint controllers.
The thirty day runbook
Day 0 to 1. Identify the person without collecting more data. Do not ask a user to upload an identity document to prove who they are when the request is about their age check. That is answering a request to hold less by demanding more. Use the authenticated session, the account, or the reference from the receipt you gave them at verification time. If you never gave them a reference, that is the first thing to fix.
Day 1 to 3. Find every copy. The database row. The vendor’s records. Your log pipeline. Your analytics warehouse. Your backups. And the support ticket where an angry adult attached a photo of their passport to appeal a false rejection. That last one catches nearly everybody, because appeals arrive by email and email keeps attachments.
Day 3 to 10. Decide per item, with the article written next to it. Keep or delete, and why, in one line each. This list is the letter. It is also the document you hand a regulator if the user complains anyway.
Day 10 to 25. Execute, and get written confirmation from the vendor. A ticket marked closed is not confirmation. A dated statement of what was deleted is.
Day 25 to 30. Answer in plain language. Say what you deleted, what you kept, the ground for keeping it, and when it goes. Tell the truth about backups: deletion propagates on the next cycle, and name the length of that cycle. Then log the whole thing, because Article 5(2) makes you responsible for showing you did it.
That runbook is also most of the work for a batch case. When a regulator makes you remove a cohort of underage accounts, you are running the same steps at volume, which is the shape we described in back book remediation.
How Xident fits
Two roles, written down before you ask. We are a processor when we run verification for a customer through the API or SDK, under that customer’s instructions. We are a controller for a Xident ID, because an end user creates that account with us and we decide what it is for. Both statements are on our GDPR page, and the data processing agreement names the sub-processors and where they sit.
Decision records instead of retained documents. Every check returns outcome, method, threshold, confidence, policy version and timestamp, and that record is what we keep. Document images are deleted within 24 hours of processing. The face embedding created for a document check is kept for a period the customer chooses, up to twelve months, and embeddings are isolated per customer at the database level rather than pooled across customers. That is the split described above, shipped as a default: the evidence survives an erasure request because the identity data behind it does not have to.
A step-up cheap enough that hoarding is not the plan. On Growth a Check is 0.02 EUR and a document Verification is 0.20 EUR. Teams keep documents “in case we need to prove it later” mostly because re-running the check feels expensive. At a tenfold gap, re-verifying is cheaper than storing, and cheaper than the letter you write after a breach.
The free sandbox grants 1,000 Checks and 100 document Verifications as one-time allowances, not a monthly quota. The 100 Verifications are there so you can run the document path end to end, including what your system holds afterwards, before you decide your retention policy in production.
The honest limits
Role allocation is decided on the facts by a regulator or a court, not by the label in your contract. The Court of Justice has read joint control broadly, in Wirtschaftsakademie and Fashion ID, and it does not require the parties to carry equal responsibility. So “we are only a processor” is a claim that gets tested, not a shield.
As far as we can find, no European data protection authority has yet published a decision squarely about erasure of age assurance records. The closest signals are adjacent: Yoti leaving Spain over Article 9 consent, and Ofcom’s September investigation into whether a platform did its own due diligence on a borrowed signal. Parts of this post are reasoning from the text and from case law, not reporting a settled outcome, and we would rather say so than imply more certainty than exists.
There is also a gap we cannot close for you. If your verification vendor is a controller for something and will not say so, the user still comes to you first, and your name is on the refusal.
The short version
One user, one sentence, three companies. Work out now which of them answers, per processing activity, and put it in the contract rather than in an email thread during the month you have.
Keep the decision and delete the material it was made from. Do not refuse an EU erasure request by citing a New York rule. Do not ask for an identity document to answer a request about an age check. Give the user a reference at verification time, so a future request can be matched without a search. And read your vendor’s reuse clause today, because it may already have made them a controller and you the one who has to explain it.
Xident provides age verification and age estimation infrastructure built around decision records rather than retained documents, with our role stated per processing activity and sub-processors named in the DPA. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us about what your current gate would have to hand over in thirty days.
