GDPR when you scan user uploads

There is a conversation that happens at almost every platform that decides to take content safety seriously. Someone proposes running uploads through a detection service. Someone else — usually whoever answers to the DPO — asks whether that is allowed under the GDPR. And the room discovers that nobody has an answer more precise than "other people do it".

The answer is that it is allowed, routinely, and that getting there takes four decisions you have to actually make rather than assume. This guide walks through them: the lawful basis, the paperwork with every processor in the content path, whether you owe a DPIA, and where the data is permitted to live. It is written for platforms of the size where the trust & safety owner and the privacy owner are the same person, or sit two desks apart.

Scanning is processing, and there is no honest way around that

An uploaded photograph is personal data about the person in it, and usually also about the person who uploaded it. Running it through a classifier is processing under Article 4(2) — collection, consultation, use — regardless of whether a human ever looks at it, and regardless of whether the file is deleted a second later.

This matters because the most common informal defence is that automated analysis "isn't really looking". The GDPR does not draw that line. Nor does deleting the file afterwards undo the processing that already happened; retention is a separate question from lawfulness, and answering the second one does not answer the first.

So you need a basis. The good news is that you almost certainly have one.

Legitimate interests is the basis that fits

Of the six bases in Article 6, two get proposed and one of them is wrong.

Consent (Article 6(1)(a)) is the wrong tool. Consent must be freely given and withdrawable. A safety control a user can switch off is not a safety control, and one they cannot switch off was never consent. Do not build on it.

Legitimate interests (Article 6(1)(f)) is the ordinary answer. Preventing your service from being used to distribute illegal material — and protecting the users who would otherwise encounter it — is about as legitimate as an interest gets. Recital 47 treats fraud prevention as a legitimate interest, and Recital 49 does the same for network and information security; content safety sits in the same family. Recital 50 points the same way: where a controller indicates possible criminal acts to a competent authority, that transmission is treated as being in the controller's own legitimate interest.

What Article 6(1)(f) demands in exchange is a documented balancing test: your interest, the necessity of the processing to serve it, and whether the data subject's rights override it. Write it down. Three pages is plenty. The parts that carry weight are: the processing is narrowly scoped to detection rather than general profiling, the output is a score rather than a dossier, the content is not retained beyond what the purpose needs, and the user was told it happens.

Legal obligation (Article 6(1)(c)) applies to the pieces that genuinely are obligations — reporting a suspicion under Article 18 of the DSA, complying with a preservation order. It does not cover the decision to scan proactively, because nothing obliges you to scan: Article 8 of the DSA rules out any general monitoring obligation. Do not stretch it to cover the scanning itself.

The Article 9 question, answered honestly

Article 9 prohibits processing "special categories" of data — including data concerning health, sex life, and biometric data used to uniquely identify someone — absent a specific exception.

Two things are true at once here, and vendors tend to mention only the convenient one.

The first: a general image classifier that returns "this image resembles abuse material" is not performing biometric identification. It does not match faces against identities, and a perceptual hash of a confirmed image is a fingerprint of the file, not of a person. On the ordinary reading, that keeps it outside Article 9(1)'s biometric limb.

The second: material of this kind unavoidably concerns the sex life of an identifiable person, and a flag attached to an account is a claim about a person. Any competent regulator will look at the whole operation, not just the classifier's architecture. The Article 9(2)(g) exception — substantial public interest, laid down by Union or member state law, with safeguards — is the one that carries the weight in practice, and it is the one your national implementing law will or will not give you.

Which is to say: this is the part of the analysis to put in front of counsel rather than settle from a blog post. What you can do without counsel is make the facts favourable — keep the processing narrow, keep the output a score, keep retention short, and keep a human in the loop before anything irreversible happens to a user.

Every vendor in the content path needs an Article 28 contract

If a third party processes content on your instructions, they are a processor and Article 28 requires a written contract with specific mandatory terms: documented instructions only, confidentiality, security measures, sub-processor rules, assistance with data-subject rights, deletion or return at the end, and audit rights.

Three practical points that get missed:

• It is not just the detection vendor. Your CDN, object storage, queue, and any human-review tooling all touch content. Each needs its own agreement. The content path is longer than the architecture diagram usually admits.
• Sub-processors are your problem too. Article 28(2) means your processor cannot silently add one. You are entitled to the list and to notice of changes. Ask for the list before you sign, not after. The Visork sub-processor list is published in the DPA rather than supplied on request.
• "We have a DPA" is not the same as "we signed one." A published template is a good sign about a vendor. It is not a contract until it is executed as part of your agreement.

Whether you owe a DPIA

Article 35 requires a data protection impact assessment where processing is "likely to result in a high risk". Systematic monitoring of publicly accessible areas at scale, and large-scale processing of Article 9 data, are both on the list — and most national supervisory authorities' own DPIA blacklists name automated content analysis somewhere.

Assume you owe one. It is not a heavy document and it is the single most useful artefact you can hold when a regulator or an enterprise customer asks how you thought about this. Cover: what is processed and why, necessity and proportionality, the risks to users (false positives being the main one), and the measures that reduce them — thresholds set deliberately, human review before account action, an appeal route, short retention, EU processing.

Write it before you deploy. A DPIA produced after an incident reads as what it is.

Residency, transfers, and why it is a design decision

If content leaves the EEA you are in Chapter V, and you need a transfer mechanism — an adequacy decision, standard contractual clauses plus a transfer impact assessment, or one of the derogations. That is workable, and it is also work, repeated for every processor and every sub-processor and revisited whenever the legal landscape moves.

The alternative is to keep the content path inside the EU and not have the conversation. For this category of data that is usually the better trade, which is why Visork treats EU residency as the standard deployment rather than an enterprise upgrade. If a vendor charges extra for it, understand that you are being sold the absence of a problem they created.

Retention is where this quietly goes wrong

The lawful basis question gets attention. Storage limitation, Article 5(1)(e), is the one that fails audits.

Decide, and write down, four separate answers:

1. The content submitted for analysis. The defensible answer is that it exists in memory for the analysis and is not persisted at all. The Visork model is analysis in volatile memory, with content deleted promptly after the verdict.
2. Flagged items awaiting human confirmation. These necessarily persist for a period. Bound it, restrict access to named reviewers, and log every access.
3. Preserved evidence. Where the law or an order requires preservation, retention follows that requirement rather than your default. Keep it in a separate store with a separate lifecycle, so "we preserved it for the police" never becomes the reason your ordinary retention rule was never applied.
4. Detection results and audit logs. Scores, thresholds, verdicts, timestamps. These are what your DSA transparency reporting and your Article 17 statements are built from, so they are retained longer — and they contain no media, which is exactly why that is acceptable.

Conflating any two of those four is how a system that was designed to delete everything ends up holding material indefinitely.

Telling users, without writing a manual for evasion

Articles 13 and 14 require you to say what you do. Your privacy notice needs to state that uploaded content is analysed automatically for illegal and harmful material, name the categories of recipients, give the lawful basis, and state the retention periods.

You do not have to publish your thresholds, your model's blind spots, or the categories it is weakest on. Transparency about the practice is required; a specification that helps someone route around it is not.

Article 22 — automated decisions producing legal or similarly significant effects — deserves a moment. A permanent account termination decided entirely by a classifier is squarely in its scope. Human review before irreversible action is the clean way out, and it is also just better moderation. It is the same reason the DSA wants a statement of reasons and an appeal: a decision nobody can explain is a decision nobody can correct.

Where this meets the DSA

The two regimes pull in the same direction more often than not, but they are separate obligations with separate paperwork:

• The DSA says you may scan voluntarily without losing your liability shield (Article 7). The GDPR is what says on what basis you may.
• The DSA requires a statement of reasons for every restriction (Article 17). The GDPR requires that the data behind it was lawfully obtained and is lawfully retained.
• The DSA requires reporting suspected serious crimes (Article 18). That is a legal obligation under Article 6(1)(c) — and it is the clean answer to "why did you keep this?" when the answer is that you were required to.

Neither regime cares that you satisfied the other one. Both files, separately.

A working checklist

1. A documented legitimate-interests balancing test for the detection processing.
2. Counsel's view on the Article 9 position under your member state's implementing law.
3. A signed Article 28 agreement with every processor in the content path — detection, storage, CDN, review tooling — and the sub-processor list for each.
4. A DPIA written before deployment, naming false positives as a user risk and the measures against them.
5. An EU-resident content path, or a transfer mechanism and a transfer impact assessment per processor.
6. Four separate retention rules — submitted content, items pending review, preserved evidence, detection logs — each with an owner.
7. Privacy notice updated: the analysis, the recipients, the basis, the periods.
8. Human review before any irreversible account action, with an appeal route that a person actually reads.

Nothing on that list requires a privacy team. All of it requires someone to decide once and write it down, which is the part that keeps not happening.

This is general information about the GDPR as it stood in July 2026, not legal advice. The Article 9 analysis in particular depends on your member state's implementing law and on facts specific to your service — take it to counsel before relying on it.