After the identity check: what happens to the ID, and who is liable if it leaks

Once identity checks are actually running on your directory, it feels like the hard part is over. The upload widget works, the pass and fail rates look sane, the advertisers who matter got through. What nobody hands you at that point is a plan for the pile of documents the check just produced, because a verification system does not consume an identity document and vanish. It produces a photograph of a face and a photograph of a government ID, and both now exist somewhere, on somebody's servers, for a length of time nobody actually decided on purpose.

This is not an argument against verifying. The law already settled that question, and skipping the check is the more expensive mistake by far. It is an argument about the part right after the green checkmark, which is the part that hurt several companies badly in 2025 and 2026, none of whom had skipped verification. They had done it correctly, then let the resulting file sit somewhere the wrong person eventually found.

The document does not disappear when the check passes

A verification flow looks simple from the advertiser's side: take a selfie, photograph an ID, wait a few seconds, get approved. Underneath, that transaction creates an artifact, the actual images, that travels from an upload form to a comparison engine and back with a result. Whether that artifact is deleted the moment the comparison finishes, or kept for a day, a month, or indefinitely, is a design decision, and most systems default toward keeping things, because deleting on schedule is a feature somebody has to build and maintain, while doing nothing is free.

What that default costs became public in July 2025, when a breach at the dating-safety app Tea exposed roughly 72,000 images, including about 13,000 photographs of government IDs and verification selfies submitted before February 2024. Tea's own privacy policy stated that verification photos were deleted immediately after use. They were not: the images had been sitting in an unsecured cloud storage bucket, a legacy system nobody had gone back to empty once the product moved on to a newer one.

The lesson has nothing to do with dating apps specifically and everything to do with the mechanism, which is generic to any business that outsources a check behind a widget. A privacy policy is a promise, not a fact about your infrastructure. If you cannot name the exact number of days between an advertiser uploading an ID and that ID being gone from every system that touched it, including backups, you do not actually know what your policy is, only what it says.

A second incident the same year showed the other common way this goes wrong: routing something sensitive through a general-purpose system instead of a dedicated one. Discord's breach in October 2025 traced back to a compromised third-party customer support vendor, because age-verification appeals, including uploaded government ID photos, had been funnelled through the same ticketing system used for ordinary complaints. Discord confirmed around 70,000 ID images and selfies were exposed, along with names, usernames, emails and limited billing details, and it has since stopped routing documents through general support entirely.

Why an ID tied to your directory is worth more to lose than the ID alone

A leaked government ID on its own is a real problem for the person in the photo, but a leaked ID that a dataset also labels as belonging to a verified advertiser on an adult listings site is a different order of problem, because the label is the damage. The label attaches a fact about that person's life they did not choose to make public, and that combination is what turns a routine breach notification into a lawsuit, or in some documented cases, extortion aimed at the person whose data leaked rather than at the company that lost it.

Regulators already treat this category of association as sensitive in its own right, independent of any single photo or message. Under the GDPR, data revealing a person's sex life or sexual orientation sits in the small set of special categories that require a much higher legal bar to process at all. Norway's data protection authority fined the dating app Grindr roughly six and a half million euros in December 2021, upheld on appeal in 2025, specifically because sharing with advertising partners the simple fact that someone was a Grindr user was itself found capable of revealing sexual orientation. No message and no photo needed to leak for the fine to apply; membership was the sensitive fact.

The same reasoning reaches a classifieds directory without much translation. A government ID that a breached dataset also marks as belonging to a verified advertiser on your platform is personal data plus an inferred life fact the subject never agreed to publish, and every liability framework built around data breaches treats that combination as more severe than an ordinary leak of card numbers from a retailer. It is a large part of why fines and lawsuits in this corner of the internet run higher than the breach headlines most businesses assume do not apply to them.

Practically, this should change what counts as adequate security on your side, even though the vendor holds the file. A database of passwords and a database that pairs a government ID with platform membership do not carry the same duty of care, and neither a regulator nor a journalist will treat them the same after an incident. It is worth deciding, before anything happens, that the second category gets a higher standard than whatever your general policy currently applies to customer data, because after an incident is not when that decision gets made well.

The retention trap: fined for what you kept, whether or not it ever leaked

The Tea and Discord cases both involve a breach, meaning an outside attacker had to do something. Spain's data protection authority showed the other route to the same outcome in March 2026, when it fined Yoti, one of the specialist identity and age verification providers, nine hundred fifty thousand euros without any breach at all. Yoti was fined for what it had simply been keeping, on file, waiting for nobody to ask.

The breakdown is worth reading closely because every line describes an ordinary, well-intentioned business habit rather than obvious misconduct. Five hundred thousand euros concerned how biometric data was processed under the GDPR's special-category rules. Two hundred thousand euros concerned consent design: users could click past the privacy policy screen without ever opening it, and were opted in by default to having their biometric data reused for internal research unless they found and unticked a box. The remaining two hundred fifty thousand euros concerned retention judged excessive, including geolocation data kept for five years after it had done its one job of establishing which age rule applied at signup, and biometric templates kept for as long as an account stayed active plus three more years after the last time anyone used it.

Every one of those retention choices had a defensible-sounding reason: geolocation in case a rule needed re-checking, biometric templates in case a returning advertiser needed re-verifying, research access to improve the product. A defensible-sounding reason is not the same as a retention period tied to a stated, specific purpose, and the regulator fined a company built around doing verification correctly for confusing the two. Yoti is appealing, and enforcement was reportedly suspended in April 2026 pending that appeal, so treat the case as a live warning rather than a closed file, but the reasoning that a retention clock has to track a purpose, not a convenience, is not the part under appeal.

The operational reading is simple to state and easy to skip: your vendor contract should name a retention period in days, tied to a stated purpose, for every category of data the check produces. If a vendor cannot give you that number in writing, they have not decided it either, and neither of you will be able to defend it later, to a regulator or to an advertiser asking where their ID went.

What to actually ask a verification vendor before you sign

In most setups you are not the one running the verification software. A specialist vendor is, which is the correct division of labour: identity checks that actually catch fake listings are a narrow, liability-heavy discipline a small team should not build from scratch. But under data protection law the operator who decided the check should happen usually remains the controller, while the vendor is a processor, and a processor's mistake still lands on the controller's liability toward the person whose document leaked. That makes the vendor contract, not a support ticket sent after something goes wrong, the place these questions belong.

Ask first whether the check returns only a pass or fail plus a confidence score, or whether the actual image passes through and rests on your own infrastructure at any point. A vendor built around a verify-and-discard design, comparing the document and deleting it within the same transaction instead of storing it for later, removes most of this risk through architecture rather than a policy promise that has to be trusted and re-checked.

Ask for the exact deletion window in days, written into the contract rather than quoted from a marketing page, and ask what happens to backups. A system that deletes the live copy on schedule but keeps a ninety-day backup has, in practice, a ninety-day retention period no matter what the headline figure says, and that gap is exactly where the Tea images survived past their supposed deletion.

Ask who notifies whom, and within how many hours, if the vendor itself is breached. You, not the vendor, may be the one who owes a regulator a report, and a seventy-two hour notification clock cannot be met on a leak you learn about in week three. Keep the answer on file before you need it: it is close to the same paperwork a payment processor already demands before it approves your account, so writing it down once serves both purposes. Put a shorter contractual deadline on the vendor than the one you owe your own regulator, so there is time to act before yours expires.

Ask, finally, what the vendor does with the image for purposes beyond the check itself: model training, shared fraud databases across their other clients, internal research. Require a clear written yes or no rather than accepting silence as an answer, because silence dressed up as a default opt-in is precisely what let Yoti's research-consent design stand as long as it did before a regulator looked closely.

What to actually do this quarter

None of this is a reason to verify less carefully. It is a reason to be as deliberate about how the data leaves your systems, and your vendor's, as you already had to become about how it comes in. The operators hurt in the next round of fines and breach headlines will not be the ones who never checked an ID; they will be the ones who checked correctly and never asked what happened next.

Start this month by requesting your current vendor's retention schedule in writing, in days, for every category of data the check produces, not in adjectives like briefly or as needed. If they cannot produce that number, the inability to answer is itself the finding, and it tells you more about the risk you are carrying than any brochure will.

Close any workflow where a support agent, an appeals reviewer, or you personally end up receiving an ID photo by email or through a general ticketing system instead of the dedicated verification pipeline. If a workflow like that exists anywhere in your operation, it is almost certainly your single largest exposure, and unlike most fixes in this business, closing it costs nothing but the decision to do it.

Put a maximum retention period and a breach-notification deadline into the next contract renewal, in writing, and calendar a check on the vendor's actual practice, not just its policy page, every two quarters. A promise true the day you signed is not guaranteed to still be true a year later, and the businesses fined or breached in 2025 and 2026 mostly found that out from a regulator or a hacker instead of from their own review.