Skip to content
Skip to main content
Cloud Services Operational Explainer

What should I preserve before changing cloud permissions or sharing settings?

Before tightening access, preserve the complete pre-change permission state and the history that created it.

Changing sharing can remove recipients, invalidate links, end access routes, generate new audit events and make the earlier configuration harder to reconstruct.

The working rule
Capture who could access what, through which route, and since when — then make the restriction a documented intervention.

Record every route into the resource

For the relevant file, folder or workspace, preserve:

  • resource ID and owner;
  • direct users;
  • external guests;
  • groups;
  • roles;
  • inherited access;
  • link IDs and types;
  • authentication requirement;
  • expiry;
  • view/edit/download rights;
  • connected applications; and
  • relevant audit history.

A current permission panel may show only the end result.

A more useful representation is the chain:

Parent folderFinance group can editAccess inherited by the file.
Direct shareExternal guest can viewNamed permission added later.
LinkExternal link activeSeparate route with its own link ID and expiry.
ApplicationConnected service can readDelegated access may survive a user-facing share change.

Removing only one route may leave the others intact.

Preserve the history, not just a screenshot

Where available, retain:

  • structured permission export;
  • audit events showing creation and alteration;
  • stable user, guest, group and link identifiers;
  • timestamps;
  • administrator or user who made each change; and
  • screenshots that show how the service presented the state.

How do I identify whether cloud data was shared externally? explains how permission history and actual access fit together.

Make the restriction traceable

For each change, record:

  • authorising decision;
  • operator;
  • exact control used;
  • time and zone;
  • provider response; and
  • verification of the effect.

A restriction timeline might read:

16:10Pre-change permission export captured.
16:14External link LNK-441 disabled.
16:17Guest G-102 removed.
16:21Verification confirms inherited Finance-group access remains.

That final check matters because cloud permissions can overlap.

Restriction cannot recall copies already made

Removing a link or permission may stop future access.

It does not automatically remove files already downloaded, exported, synchronised or copied elsewhere.

Assess those separately.

The practical point is: preserve the full permission chain before changing it, then document and verify each restriction as a new evidential event.

Reference: CLD-173Cloud Services