Two days after the archive goes live, a speaker emails the program chair: “Please cut my session.” The program chair forwards it to you at 9:40pm. You have a published recording, a transcript, a clip in the sponsor reel, and a platform retention setting you did not configure. What you do next depends entirely on records you either have or do not have.
This is a hypothetical scenario, not a documented case. But the operational problem it describes is real, and the artifact that solves it is boring: a consent ledger. Not a policy document. A table with named owners that the person on call at load-in can actually read.
Why “delete the video” is the wrong first move
Erasure rights are conditional. Under the GDPR, the right to erasure applies on specified grounds, including when the data subject withdraws consent and there is no other legal ground for processing (Art. 17 GDPR). But the same article lists exceptions, including processing necessary for exercising the right of freedom of expression and information. The UK Information Commissioner’s Office states plainly that the right “is not absolute and only applies in certain circumstances” (ICO, Right to erasure).
That means the first question is not “how do we delete this?” It is “on what basis are we holding this recording, and does that basis survive the request?” If your answer is “we have a signed release form,” that is a fact you can check. If your answer is “I think someone signed something,” you cannot triage the request at all.
The ICO also notes that an erasure request can be made verbally or in writing, and does not have to be directed to a specific person or contact point. A request received by a volunteer at the registration desk is still a request. You have one month to respond, without undue delay. The clock starts on receipt, not on the day it reaches your inbox.
What the ledger must contain per speaker
The unit of reversibility is not a person. It is an artifact. A single speaker may appear in the main session recording, a per-presentation cut, a highlight clip, a transcript, a thumbnail, and a sponsor reel. Each of those has a different storage location, a different owner, and a different deletion path. A single “consented: yes/no” flag per speaker cannot answer the question “what exactly do we need to remove?”
So the ledger is keyed to artifacts, with the speaker as a foreign key. For each artifact, you need:
- Speaker identity — name, role (author, panelist, moderator, keynote), and the session identifier.
- Consent status — opted in, opted out, or not applicable (e.g., an author who opted out via the rights form).
- Basis — consent, contract, legitimate interest, or an exemption. This is the column that determines whether the request can be refused, partially complied with, or must be honored.
- Artifact type — main recording, per-presentation cut, clip, transcript, thumbnail, sponsor reel.
- Storage location — the platform, bucket, or drive where the artifact actually lives.
- Publication status — published, scheduled, draft, or never published.
- Retention window — the date the artifact is scheduled for deletion or review.
- Named owner — the person who can actually delete it.
- Backup overwrite date — when the artifact will be beyond use in backups.
The basis column is the one that earns its keep. Without it, you cannot distinguish a speaker who withdrew consent from a speaker whose recording is held under a separate contractual license. Those two situations have different answers.
Where the raw data already lives
You are not collecting new data. Conference recording workflows already generate most of what the ledger needs. The problem is that it lives in different systems owned by different people.
ACM’s recording requirements, for example, state that authors opt in or out of video recording when they complete the ACM eRights Form. The Conference Chair is required to request from the ACM Rights Form contact a list of authors and corresponding proceedings articles that have opted out, and provide that list to the videographer. The videographer must also secure a signed Permission and Release Form for any individual appearing on media who is not an author of a paper (ACM, Digital Library Recording Requirements).
That is already a consent record. It is just not in a table you can query. The same is true of the release forms themselves. A speaker release form can grant a nonexclusive license to use, modify, publish, reproduce, distribute, publicly display, and archive presentation materials, while the speaker retains ownership of the underlying materials and the organization retains rights in the resulting media (AHLA Speaker Release Form). Another form can state that all rights to the recordings belong exclusively to the organization, while the speaker retains intellectual property rights to the underlying presentation (NATCA Event Speaker Consent and Release Form). These are examples of drafting, not legal conclusions, but they show the range of terms you may be reconciling.
Platform retention settings are the third input. Microsoft Teams live event recording policies, for instance, include a setting that determines whether an MP4 is created and stored for 180 days, and a separate setting where disabling attendee recording causes the AMS asset to be deleted after the event (Microsoft Learn, Live event recording policies). That 180-day figure is specific to one platform’s storage behavior. It is not a legal or industry standard. But it is a real retention window that belongs in your ledger.
The ledger’s job is reconciliation. Pull the opt-out list, the signed forms, the per-presentation file naming convention, and the platform retention settings into one table. If you cannot reconcile them, you do not know what you have.
The reversibility test
Before you publish any recording, run this test on each artifact: can you name the storage location, the retention window, and the person who can delete it? If any of the three is unknown, the artifact is not reversible. Do not publish it until it is.
This test is cheap to run and it surfaces the artifacts that will cause trouble later. A clip embedded in a sponsor reel is a common failure point, because the sponsor reel may be owned by a different team than the session archive. A transcript generated by a third-party service may live in a different bucket than the video. A thumbnail may be cached by a CDN that you do not control.
Backups change what “deleted” means. The ICO’s guidance states that if a valid erasure request is received and no exemption applies, you must take steps to ensure erasure from backup systems as well as live systems. The steps depend on your retention schedule and technical mechanisms. The key issue is to put the backup data “beyond use” — not served, not indexed, not reused — even if it cannot be immediately overwritten. The operational target is therefore not “physically deleted everywhere” but “beyond use, with the overwrite date recorded.”
That distinction matters when you are writing the response to the speaker. You can say what you have done and when the backup copy will be overwritten. You cannot say the data no longer exists anywhere if it is still in a backup rotation.
A consent ledger schema you can copy
The following schema is a recommendation, not a standard. It is designed to be readable by the person who has to act on it at 11pm during load-in.
| Column | Allowed values | Notes |
|---|---|---|
| speaker_id | text | Stable identifier, not just name |
| session_id | text | Matches program schedule |
| role | author, panelist, moderator, keynote, other | Determines which form applies |
| consent_status | opted_in, opted_out, not_applicable, unknown | “Unknown” is a valid and useful value |
| basis | consent, contract, legitimate_interest, exemption, unknown | Required for triage |
| artifact_type | main_recording, per_presentation_cut, clip, transcript, thumbnail, sponsor_reel | One row per artifact |
| storage_location | text | Platform, bucket, or drive |
| publication_status | published, scheduled, draft, never_published | Published includes embedded copies |
| retention_window | date | When the artifact is scheduled for deletion or review |
| owner | name or role | The person who can delete it |
| backup_overwrite_date | date | When the artifact is beyond use in backups |
| request_log | text | Date, channel, and who received any erasure request |
Three queries the ops lead runs on any erasure request:
- What do we have? Select all rows for the speaker where publication_status is published or scheduled. This tells you the scope of the request.
- On what basis? Select the basis column for those rows. If any row has basis = consent and no other legal ground, that row is the one that needs action. If basis = contract or exemption, you need to check whether the exemption applies.
- Who can act? Select the owner and storage_location for each row. If the owner is unknown, the artifact is not reversible and you have a problem to fix before you respond.
The ledger also needs a front door. Because a request can arrive verbally and to any part of the organization, designate a single intake path — an email alias or a form — and log every request, including verbal ones, in the request_log column. The ICO recommends keeping a log of verbal requests. This is not bureaucracy; it is how you avoid losing a request that arrived at the registration desk on the last day of the conference.
What the ledger does not do
A consent ledger does not satisfy a legal obligation in any jurisdiction. It does not determine whether a recording is personal data in a given case. It does not make a release form enforceable. It does not tell you whether GDPR or UK GDPR applies to your event. Those are questions for counsel, and they depend on facts the ledger helps you assemble but does not resolve.
What the ledger does is make the facts visible. It turns “I think we have a form somewhere” into “row 47, basis = consent, owner = AV lead, storage = platform bucket, retention window = 180 days, backup overwrite = 2026-11-01.” That is the difference between a triageable request and a guess.
The one rule that survives every jurisdiction
If you cannot state the basis on which you are keeping a recording, you cannot defend keeping it. That rule does not require a lawyer to apply. It requires a table with a basis column and a named owner. Build the table before the first session is recorded, not after the first request arrives.
The speaker who asks to be cut two days later is not the problem. The problem is the two days you spent not knowing what you had.
FAQ
Does a speaker’s request to be cut from the archive mean we must delete the recording?
Not necessarily. Erasure rights are conditional and subject to exceptions. The answer depends on the basis on which you are holding the recording and whether an exemption applies. The ledger’s basis column is what lets you triage the request rather than guess.
What if the request arrives verbally at the registration desk?
It is still a request. The ICO states that an individual can make a request for erasure verbally or in writing, and it does not have to be directed to a specific person or contact point. Log it in the request_log column and route it to the single intake path.
Do we have to delete from backups too?
If a valid erasure request is received and no exemption applies, the ICO states you must take steps to ensure erasure from backup systems as well as live systems. The operational target is to put the backup data beyond use — not served, not indexed, not reused — and record the overwrite date.
How long do we have to respond?
Under the UK GDPR, you must respond without undue delay and within one month of receipt. The clock starts on receipt, not on the day it reaches the right person.
Is the 180-day retention window a legal requirement?
No. The 180-day figure comes from Microsoft Teams live event recording policies and describes one platform’s storage behavior. It is not a legal or industry standard. Your retention window should come from your own schedule and any applicable legal requirements.
Where does the consent data come from?
From workflows you already run: opt-in/opt-out lists from rights forms, signed release forms, per-presentation file naming, and platform retention settings. The ledger reconciles them; it does not replace them.
Related reading: Why Hybrid Events Fall Apart at the Room-to-Chat Handoff — the same reconciliation problem, applied to the boundary between the physical room and the chat channel.