One Approved Meeting Recording Became Two Shared Objects After Release: Choose the Authority

Choose one release authority. A released duplicate is not harmless because each object can retain a separate link, recipient list, onward-share path, and retention state.

Start by freezing new sharing on both objects. Preserve the evidence needed to compare them, then direct future access to the object that becomes the authority.

This is a records-control workflow. It does not decide whether a recording should have been released. It decides which already approved object is the controlled copy after duplication.

Do both recording objects contain the same approved content and redactions?

Do not choose the survivor by filename or folder alone. An upload date alone is also insufficient. Compare the actual files and the release package attached to each one.

Create a cryptographic hash for each downloadable file where your process permits it. A matching hash supports a finding that the underlying files match. A different hash means the objects need a content review before any cleanup.

Then compare the approved version, redaction record, captions or transcript if included in the release, title and description. Also compare any attached approval note. A copy can have the same video while carrying a different transcript, link setting, or approval context.

In Teams, recordings for private meetings and channel meetings can land in different storage locations. Microsoft says private meeting recordings are uploaded to the organizer's OneDrive, while channel meeting recordings are stored in the channel's SharePoint location.

• Record each object ID, URL, storage location, creator, creation time, and file hash.
• Record the release approval and redaction version that applies to each object.
• Mark any difference as unresolved until a reviewer decides whether it changes the approved release.

Which recipients accessed or shared each object?

Build separate access histories. Do not assume that a duplicate inherited the first object's recipients or that revoking one link revokes the other.

For each object, export or record the current permission list, every known sharing link, the recipient scope, and available audit evidence for access or onward sharing. If a platform cannot provide a complete history, write that limitation into the ledger instead of filling the gap with an assumption.

Check direct permissions and links separately. A recipient may have access through a shared link even when they are absent from a manually maintained recipient list.

Microsoft states that users with full edit rights on a Teams recording file can change permissions and share the file later. That makes the current permission state and available sharing history relevant to the survivor decision.

Which object should survive?

Choose the object that has the clearest approved lineage, the correct redactions, the intended recipient scope, and a retention state the records owner can administer. If those answers point to different objects, stop and escalate the conflict rather than combining facts from both into a convenient answer.

The survivor should have a stable canonical URL and a named business owner. It should also have an explicit release record. Put that URL in the replacement notice to authorized recipients.

Use the ledger to document the decision in plain language: which object survives, why it survives, who approved the decision, which links were revoked, and which retention control now governs the controlled copy.

• Keep the object with the approved content and redactions.
• Prefer the object whose permissions match the intended release population.
• Require the records or legal owner to confirm retention and hold status before deletion.

How do you unify access and retention after choosing the survivor?

Make the survivor the only active release path. Where the platform allows it, remove or disable duplicate sharing links. Remove direct permissions that are no longer needed. Send authorized recipients the survivor URL.

Do not promise that removing a link erases copies already downloaded or shared outside the controlled platform. Record the known limit and the recipient notice. Also record the action taken.

Retention needs its own review. Microsoft says that Teams recording expiration settings are not a substitute for legal protection because users who control recordings can modify their expiration date. Microsoft also states that file retention takes precedence over meeting recording expiration when a Purview retention policy applies.

If either object is subject to a hold, retention policy, retention label, investigation, or disposal review, preserve it according to that control. The duplicate may be hidden from ordinary release access while still retained for compliance.

What should the release owner do next?

Assign one reviewer to complete the authority ledger and one owner to execute approved access changes. Keep those roles separate when the release has legal or compliance implications, including sensitive-personal-data implications.

Close the incident only after the survivor URL works for the intended recipients, duplicate links are revoked or recorded as unavailable to revoke, retention has been confirmed, and the ledger names the reviewer and decision date.

For a broader operating framework, read the Well Met guide.