A Released Meeting Recording Lost Its Redaction-Manifest Link: Revoke and Revalidate

A released recording with no working path to its redaction manifest has a provenance problem. You may still have the video. You may still have one or more manifests. What you cannot prove is which manifest authorized the released version.

Contain the uncertainty first. Remove or disable the active share link, preserve the recording and every candidate manifest, then reconstruct the relationship from hashes, using version history to compare approval records with recipient evidence.

For Teams recordings, the storage location depends on the meeting type. Microsoft documents that scheduled meeting recordings generally save to the organizer's OneDrive, while channel meeting recordings save to the channel's SharePoint location. Start your evidence collection at the actual storage location rather than assuming every recording has the same owner or permission model. Microsoft Learn, September 23, 2026

When must access be revoked while the relationship is reconstructed?

Revoke access unless evidence establishes a single governing manifest for the released recording and its recipient list. The point is to stop further distribution while the evidence remains ambiguous.

A broken metadata link alone does not prove that the recording was improperly redacted. It does prove that the release relationship needs revalidation. Preserve the original file and records before anyone changes links or files.

For SharePoint and OneDrive, Microsoft says you can stop sharing with guests by removing their permissions from the shared item or removing them as directory guests. For an Anyone link, delete the link or disable Anyone links for the site. Microsoft Learn, May 7, 2026

• Revoke the active recording link and record the time, actor, scope, and reason.
• Do not overwrite the released recording or candidate manifests during containment.
• Capture the recipient list, link type, permissions, and any known downloads or shares before the records change.
• Keep the incident record separate from the evidence ledger so later edits remain visible.

Which manifest governed the intact released recording?

The governing manifest is the version that can be tied to the released recording by the strongest available chain of evidence. Start with a cryptographic hash of the intact recording and each candidate manifest. Then compare release approval time, manifest version identifier, storage version history, and the file or link named in the approval record.

Do not choose the newest manifest because it looks right. Do not choose the file stored nearest to the recording. Those are clues, not proof. If the evidence remains split, keep access revoked and send the relationship to the authorized reviewer for a decision.

Microsoft notes that SharePoint and OneDrive audit records can support investigation of user activity, but it does not guarantee a fixed time for every audit record to appear. For core services including SharePoint and OneDrive, Microsoft describes typical availability as 60 to 90 minutes after an event. Build the recovery timeline with that delay in mind. Microsoft Learn

What belongs in the recording-to-manifest recovery ledger?

Use one ledger row for the released recording and one row for every candidate manifest. Keep each record's original identifier, hash, timestamp, location, and approval artifact. The ledger should show how you moved from an uncertain relationship to a corrected one.

The ledger is not a substitute for the manifest. It is the audit trail for the reconstruction work. Store it with the incident record and protect it from casual editing.

How do you reconstruct the missing relationship without corrupting evidence?

Make read-only copies for investigation if your process permits it. Calculate and record hashes before analysis. Export version history, sharing details, approval messages, and audit events into the case record. Keep source filenames and IDs unchanged in the evidence copy.

Build a timeline from the recording creation, manifest creation, redaction review, release approval, sharing event, and link-loss discovery. Each event should point to a source record. Mark gaps as unknown rather than filling them with a likely explanation.

NIST's incident response guidance is intended to help organizations prepare for, detect, respond to, and recover from cybersecurity incidents within risk management activities. A documented containment and recovery sequence gives the release decision a traceable basis. NIST, April 2025

• Hash the intact recording before opening it in an editor or moving it.
• Hash every candidate manifest and retain its original version identifier.
• Export evidence of approvals and sharing events with their source locations.
• Record each inference and name the artifact that supports it.
• Escalate unresolved conflicts to the person authorized to approve the corrected relationship.

How should you control access during the review?

Use the narrowest containment that stops further release while preserving the investigation path. A direct share removal may be enough for one item. A broader site or OneDrive control may be appropriate when the review scope includes multiple linked files.

Microsoft documents a SharePoint and OneDrive block-download policy that can provide browser-only access while preventing download, print, sync, and app access. Microsoft also recommends testing the policy with the applications your organization uses because it can affect the user experience. Microsoft Learn, May 14, 2026

Do not treat a block-download policy as proof that previous recipients did not download a file. It is an interim access control. Keep the recipient and sharing evidence in the ledger, then follow all applicable organizational requirements.

What must happen before the recording is released again?

The reviewer should approve a specific edge: this recording hash and version is governed by this manifest hash and version. The approval should identify the evidence reviewed. It should also state the decision time and the scope of the restored audience.

Create a new share or reactivate access only after that approval. Do not quietly reuse the old link if it prevents you from distinguishing the corrected release from the uncertain one. Record the new link state and the restored recipients in the ledger.

NIST SP 800-53 describes security and privacy controls as flexible and customizable within an organization-wide risk-management process. Your reapproval step should follow the authority and controls your organization has defined, rather than a generic approval threshold. NIST, September 2020