Decision guide · Collaboration governance

Sprawl isn't a training problem. It's a decision nobody made.

Teams, SharePoint, shared drives, and whatever file-sharing tool a project picked up along the way all grew past the point anyone set the rules on purpose. Collaboration governance names who owns the defaults everyone is already living with.

Frame the sharing question

The default somebody accepted three years ago is now the policy.

Every new team, every site, every shared link starts from a default nobody chose deliberately - often "anyone with the link can view," because that was the fastest option during a rushed setup or a project under deadline pressure. Whether the platform is Microsoft 365, Google Workspace, or something else entirely, the pattern is the same.

Sites and teams also get created faster than anyone retires them. A project wraps up and its team lingers, its files still shared exactly the way they were on day one, discoverable by search long after anyone remembers why. Reminding staff to "share responsibly" doesn't fix a default that was never actually decided.

Collaboration governance treats the sharing default, the creation rule, and the retention period as decisions with a named owner - separate from which chat or file-storage product happens to be running underneath them.

Boundary

This is a governance and decision-rights lens on collaboration platforms. Configuring the platform itself, and day-to-day site or team administration, remain separately scoped technical work.

Decision roles

Four decisions hiding inside "collaboration."

Default

Set the external-sharing baseline

The setting nobody consciously chose becomes the policy everyone lives with.

Approve

Allow the exception

A genuine business need for wider sharing still needs a named yes, not silence.

Retain

Decide how long content lives

Without a retention call, everything is kept forever by default, or lost the moment someone leaves.

Review

Audit sprawl on a cadence

Sites, teams, and channels outlive the projects that created them unless someone checks.

Ownership lenses

Six questions before the next site or channel.

External-sharing defaultIs the baseline "anyone with the link," specific people, or organization-only - and did anyone actually choose it?
Site & team creationCan anyone spin up a new team or site, or does it go through a named approval?
Retention & deletionHow long does content live after a project ends, and who decided that number?
Guest access reviewHow often is external guest access compared against who still actually needs it?
Orphaned contentWhen a project ends or a person leaves, who's responsible for what they leave behind?
Discoverability riskCould a sensitive file turn up in an internal search because "shared" defaulted wider than intended?

Working process

Decide the defaults before the next team gets created.

Inventory what already exists
Site, team, and channel count, plus current sharing defaults - as configured, not as assumed.
Name the setting owner
One role who can actually change the external-sharing baseline and creation rules.
Set a retention period
Agree how long content lives by default, and who is allowed to extend it.
Schedule a sprawl review
A periodic pass over guest access, dormant sites, and orphaned content.

Sharing defaults are one setting inside the same tenant this broader ownership decision covers

Hypothetical pattern

A project team, still wide open two years after the project ended

A cross-functional project spins up a team and a site under deadline pressure, sharing set to "anyone with the link" so nobody has to chase permissions mid-sprint. The project finishes. Nobody archives the team, tightens the sharing, or checks who still has the link. It surfaces two years later when an unrelated search turns up a file that should never have been that easy to find. The useful decision was never a training reminder - it was naming who owns cleanup once a project ends.

See how departing staff leave the same kind of orphaned access behind

Next step

Bring the team or site nobody has revisited since it was created.

A focused brief can turn an accepted default into a named owner, a retention period, and a sprawl review that actually happens.

Build the governance brief

The default somebody accepted three years ago is now the policy.

Set the external-sharing baseline

Allow the exception

Decide how long content lives

Audit sprawl on a cadence

Inventory what already exists

Name the setting owner

Set a retention period

Schedule a sprawl review

A project team, still wide open two years after the project ended

Bring the team or site nobody has revisited since it was created.

Get IT decisions made, and made to stick.

Related services