A Release and a Statutory Right Are Not the Same Kind of Thing
A model release is a private contract. It grants the photographer specific permissions to use the model's likeness, within a scope the contract defines. The legal force comes from contract law: offer, acceptance, consideration, capacity, and the rules of whichever jurisdiction the parties are in. Releases are negotiable, scoped, and — if drafted properly — enforceable against the party who signed them.
The right to be forgotten is something else entirely. It is a statutory right under Article 17 of the GDPR (and the UK GDPR, and equivalent regimes elsewhere). It exists because data protection law treats personal data — including photographs of identifiable people — as a category that natural persons cannot fully alienate. A signed release does not extinguish it, because the data subject cannot pre-waive certain statutory rights by signing a private agreement. The two instruments sit on different legal foundations.
The model release
Source of authority: private contract law.
What it does: grants the photographer specific usage rights, scoped to media, territory, duration, and purpose, in exchange for consideration.
What it does not do: extinguish the data subject's statutory rights to access, object, withdraw consent, or seek erasure.
The right to be forgotten
Source of authority: data protection legislation (GDPR Article 17 and equivalents).
What it does: preserves the data subject's statutory right to seek erasure on specific grounds, regardless of contractual position.
What it does not do: automatically delete every record of every past use, or retroactively invalidate uses that were lawful when they occurred.
The interaction between these two layers is the entire story. Each does real work. Neither cancels the other. The recurring error is to treat one as a complete answer to the other.
How Each Side Misreads What the Other Holds
There are two failure modes I encounter again and again, and they are mirror images of each other.
The photographer's error is to treat the release as a final settlement. "We signed a release, so the model can't ask for the content to come down." A release this absolute does not exist in jurisdictions that have data protection regimes. Even a broadly drafted release with an "all uses, all media, in perpetuity" clause does not displace statutory rights that the data subject retains by operation of law. When a regulator or a court engages with an erasure request, the release is part of the analysis — it is not the whole of it.
The model's error is to treat the right to be forgotten as a button that, once pressed, undoes every use of the content everywhere. It is not. Article 17 is not absolute. It is a structured right with specific grounds and specific exceptions, and it operates forward rather than retroactively. A withdrawal of consent does not unwind past licensed uses that were lawful when they occurred. An erasure request does not automatically defeat retention grounds like freedom of expression, the establishment or defence of legal claims, or, in some circumstances, legitimate interests.
Both errors come from the same place: assuming that one instrument is doing the work of both. It is not. Each does part of the work, and the part each does only stands up if the other is also respected.
Why "What's the Lawful Basis?" Is the Question Most Releases Don't Answer
Under GDPR, every act of processing personal data needs a lawful basis. For commercial photography, that basis is usually one of three. The choice matters more than most release templates acknowledge, because the basis determines what the model can do next.
Consent
Fragile. The model can withdraw at any time, and withdrawal must be as easy as giving consent. Once withdrawn, you need another lawful basis or processing must stop.
Legitimate interests
Sturdier. Relies on a documented balancing test. The model cannot withdraw what they never consented to, but they can object under Article 21 and the controller must demonstrate overriding grounds.
Contract necessity
Narrow. Only covers processing actually necessary for performance of the contract — rarely the full lifecycle of commercial image use beyond the immediate assignment.
Most paper releases identify none of these explicitly. They grant rights, they collect a signature, and they leave the question of which Article 6 basis is being relied on entirely unaddressed. This works fine until something contested happens — at which point the absence of a stated basis becomes the photographer's problem to argue and the model's leverage to dispute.
"A release that grants every possible right but doesn't say which lawful basis the processing relies on is doing only half the job. The other half is what the data subject still retains — and that half cannot be drafted away."
The Right to Erasure Is Real — and It Is Not a Magic Button
Article 17 of the GDPR codifies the right to erasure. It applies where one of six specific grounds is met: the data is no longer necessary for the original purpose; consent is withdrawn and no other basis applies; the data subject objects and there are no overriding legitimate grounds; the data was unlawfully processed; erasure is required by law; or the data was collected from a child in specific contexts. None of these are automatically satisfied by a model deciding they would prefer the images no longer existed.
It is also subject to substantive exceptions under Article 17(3). Retention may remain lawful where it is necessary for freedom of expression and information, for compliance with a legal obligation, for archiving in the public interest, scientific or historical research, or — significant for photographers and platforms — for the establishment, exercise, or defence of legal claims. These exceptions exist, they have weight, and they are applied case by case rather than asserted in the abstract.
What this means in practice is that an erasure request is the start of a structured process, not an automatic outcome. The data subject sets out the grounds; the controller assesses them, applies any relevant exceptions, and either complies, complies in part, or declines with reasons. Either side can escalate to the data protection authority. The release does not short-circuit this process, and neither does the withdrawal of consent. They are inputs to it.
What the Law Actually Expects Every Party to Be Able to Prove
This is where the practical reality of compliance lives, and where most workflows fail in ways that nobody notices until a dispute arises. Regulators, courts, and platforms all expect each party to a content authorisation to be able to demonstrate four things.
- Who consented, with verified identity. Not a name on a form — an identity that can be confirmed against an independent source. A scanned passport in an email and a typed signature do not meet this standard in any modern compliance regime, and never really did.
- What exactly was consented to. The scope of the authorisation: which media, which uses, which territories, which duration, which lawful basis. Vague "broad rights" language tends to be construed narrowly by the people who later have to interpret it.
- When the consent was given, and on what evidence. A timestamp from an unverified PDF means very little. A cryptographically anchored signature with a verifiable time source means a great deal. The difference is the gap between an assertion and a fact.
- What happened when the consent status changed. If consent was withdrawn, when? By whom? Were the affected platforms informed, and did they acknowledge? The audit trail of what each party knew, and when, is the single most decisive evidence in any dispute that actually reaches a decision-maker.
Most paper-based or scanned-PDF workflows fail at one or more of these. The model release exists; the lawful basis is unstated; the timestamp is unverifiable; the withdrawal process is undefined. When everything goes well, none of this matters. When it does not, it matters more than anything else in the file.
The Compliance Picture Needs a Third Layer
If you accept that the contract layer (the release) and the statutory layer (data protection law) both exist and neither cancels the other, the next question is the practical one: how do you actually operate inside that two-layer reality?
The answer is that operational compliance is its own layer. The contract does not enforce itself, and the statute does not produce its own evidence. What sits between them — the layer that determines whether anyone can actually demonstrate what was consented to, by whom, and what happened when consent changed — is operational infrastructure. It is the verified record. It is the audit trail. It is the proof.
This is the reason I wrote last week's piece on ProntoTag's deliberate boundary. ProntoTag is not a substitute for a model release; it generates one in a verified form. It is not a substitute for data protection law; it produces the evidentiary record the law expects parties to be able to produce. It does not enforce anything itself — it provides the verified facts that the parties with enforcement authority need in order to act correctly.
Compliance Is Not a Document. It Is a State.
The instinct to treat compliance as a document — "we have a signed release, we are compliant" — is one of the most reliable sources of failure in this whole area. A signed release is a record of an event. Compliance is a continuing state, with obligations that survive the signing and that have to be observable across every party throughout the lifecycle of the content.
The contract layer and the statutory layer will continue to coexist imperfectly. The realistic goal is not to reconcile them. It is to make sure that — whatever question gets asked about who consented to what, and when, and what happened when it changed — every party can answer it from the same verified record.
Two Layers, Operating in Parallel, With a Third Layer Holding the Evidence
The release does what it does well — it grants contractual rights with defined scope between parties who agreed to specific terms. The right to be forgotten does what it does well — it preserves statutory rights that the data subject retains regardless of contract. Neither replaces the other. Neither was designed to.
The discipline this requires is not legal expertise. It is operational honesty. A release that names its scope precisely and identifies its lawful basis. A withdrawal process that is defined in advance rather than improvised under pressure. An audit trail that records what each party knew, signed, withdrew, and acknowledged, in a form that holds up to scrutiny. When the contract layer and the statutory layer disagree about what should happen next — and sometimes they will — the verified record is what makes the disagreement resolvable instead of intractable.
This is the work. The releases will be there. The statutory rights will be there. The disputes will continue to occur. The question is whether, when they do, each party can speak to what actually happened with verified evidence, or whether the conversation collapses into competing recollections of a moment nobody captured properly. The first scenario is workable. The second is the one I built ProntoID products to make less common.
This article is general information about the interaction between model releases and data protection rights. It is not legal advice. Photographers, models, and platforms with specific questions — particularly in cross-border situations or where a dispute is already underway — should consult qualified legal counsel in the relevant jurisdiction. ProntoID provides verified identity and content attribution infrastructure; it does not provide legal services.