SharePoint architecture and collaboration governance

SharePoint Site Provisioning Governance Guide

Govern how SharePoint sites enter the tenant: who may create them, which business need they serve, what site and identity model is correct, which owners are accountable, what protection and lifecycle defaults apply, and what evidence proves the result matches the approved request.

Team sites, communication sites, Teams, and channel sites
Request, owner, name, URL, template, and hub
Sensitivity, sharing, retention, lifecycle, and evidence
Request a SharePoint governance review
Review the broader site governance model

SharePoint site provisioning governance studio for request intake, ownership, templates, sensitivity, hub association, and lifecycle controls
A governed site moves through request, ownership, architecture, protection, validation, and lifecycle gates before it becomes an approved collaboration workspace.

Provisioning objective

Control the outcome across every creation path

SharePoint sites are not created only from the SharePoint start page. A Microsoft 365 group, Microsoft Team, private or shared Teams channel, admin action, PowerShell command, REST or Graph workflow, migration tool, and third-party application can create or depend on a site. Disabling one SharePoint button does not close all of those paths.

Provisioning governance defines the approved workspace patterns, creation authorities, required request data, automation identity, policy defaults, validation evidence, exception handling, and lifecycle owner. The objective is not to block useful collaboration. It is to make every site intentional, supportable, discoverable, appropriately protected, and removable when its purpose ends.

Minimum approval and evidence packet

  • Business purpose, audience, data categories, geographic or regulatory constraints, and expected lifespan.
  • Site type, connected Microsoft 365 group or Team, channel relationship, URL, alias, and naming-standard result.
  • Two accountable owners where practical, sponsor, support queue, and owner-replacement process.
  • Template/script version, information architecture, hub association, storage baseline, and approved apps or automation.
  • Sensitivity, privacy, external-sharing, unmanaged-device, default-link, retention/DLP, and access baseline.
  • Created object IDs, group/site/Team relationship, timestamp, creator identity, validation results, exception, and next review date.

Control boundary: the SharePoint “Users can create sites” setting controls creation from SharePoint, OneDrive, PnP PowerShell, and the REST API, but it does not stop users from creating Microsoft 365 groups or Teams that automatically create connected SharePoint sites. Govern group and Team creation as part of the same provisioning architecture.

Six decision gates

Approve the workspace before automating the build

Automation makes good decisions repeatable—and bad decisions repeat faster. Keep these decisions explicit even when the final provisioning action is fully automated.

Need

Confirm a new site is necessary and an existing site, library, Team, or controlled folder cannot meet the requirement.

Workspace type

Select group-connected team site, communication site, Teams-connected site, channel site, or approved special pattern.

Identity and owners

Define the Microsoft 365 group relationship, privacy, members, two owners, sponsor, and support responsibility.

Information architecture

Approve URL, name, template, libraries, metadata, content types, navigation, hub, storage, and integration boundaries.

Protection

Apply sensitivity, sharing, guest, unmanaged-device, default-link, retention, DLP, and restricted-access decisions.

Evidence and lifecycle

Validate the result, record IDs and policy state, schedule owner attestation, inactivity review, archive, and deletion criteria.

Creation path What it creates Primary control plane Evidence to retain
SharePoint create-site experience Communication site or Microsoft 365 group-connected team site, depending on tenant settings and user choice SharePoint admin center site-creation settings, group-creation authority, sensitivity labels, naming and provisioning policy Requester/creator, selected type, group and site IDs, URL, label, privacy, owners, template, validation
Microsoft Teams Team, Microsoft 365 group, connected team site, and later separate sites for private/shared channels Teams creation, Microsoft 365 group creation, naming/classification, sensitivity, channel policy, SharePoint defaults Team/group/site relationship, owners, members/guests, label, privacy, channel sites, lifecycle linkage
Microsoft 365 group services Group-connected SharePoint team site plus related mailbox, Planner, and other group resources Entra/Microsoft 365 group creation controls, naming policy, sensitivity labels, expiration, owner governance Group ID, site URL/ID, workload relationships, owners, alias, label, expiration and renewal state
Admin or workflow Communication, group-connected, or nongroup site with selected settings and post-provisioning actions SharePoint admin center, Graph/REST, SharePoint Online/PnP PowerShell, Power Automate/Azure automation identity Request/approval, automation version, app or managed identity, parameters, output IDs, errors, retry and rollback
Migration or third-party app Sites and structures created by migration tooling or app permissions, sometimes outside the normal request experience Migration governance, app consent, restricted site creation by apps where licensed/supported, vendor configuration App ID, permission scope, approved site types, batch manifest, exceptions, failed objects, post-migration validation

Site-type decision

Choose the collaboration model before the template

Group-connected team site

Use when a defined membership collaborates on files, lists, tasks, and related Microsoft 365 group services. Manage membership through the associated group rather than building parallel direct SharePoint permissions. Decide whether a Team will also be needed before users create a duplicate workspace.

Communication site

Use for broad publishing with a small author group and a larger reader audience. It is not connected to a Microsoft 365 group; use the standard SharePoint Owners, Members, and Visitors model and keep editorial responsibility explicit.

Teams channel site

Private and shared channels create separate SharePoint sites with membership controlled through Teams. Do not provision or manage them like ordinary standalone sites. Record the parent Team, channel type, membership boundary, sensitivity inheritance, retention, and lifecycle relationship.

Architecture rule: hub association improves navigation, branding, content rollup, and search context; it does not grant access or replace permissions. Use the SharePoint hub site architecture guide for hub boundaries and association governance.

Controlled runbook

Provision, validate, and hand off in a reversible sequence

Capture the business request

Record purpose, sponsor, audience, data categories, internal/external collaboration, expected volume, geography, integrations, search/Copilot expectations, records obligations, launch date, and sunset trigger. Reject duplicate or vague requests for clarification.

Search for an existing workspace

Check active sites, Teams, hubs, project portfolios, naming aliases, recent requests, and archived workspaces. Reuse or extend an existing governed space when ownership and information architecture make that safer than another site.

Select the site and identity model

Choose team versus communication site, group-connected versus nongroup, Team requirement, channel relationship, privacy, member source, guest requirement, and whether access should be assigned through a group rather than individuals.

Reserve name, alias, and URL

Apply business-friendly naming, blocked words, department/region/project conventions, alias uniqueness, URL-safe values, and privacy-conscious wording. Treat URLs as durable identifiers; later renames can affect integrations, bookmarks, sync, scripts, and user support.

Verify owner readiness

Confirm at least two active owners where practical, an accountable sponsor, training, owner-removal workflow, support route, external-sharing responsibility, and periodic recertification. Do not accept a shared mailbox or departing contractor as the only owner.

Apply template and baseline

Use an approved site template/site script version to create libraries, lists, content types, metadata, theme, navigation, and logging hooks. Record which actions completed, failed, or require a second-stage automation job.

Apply policy and architecture

Set sensitivity, privacy, external sharing, default link, unmanaged-device access, restricted access/discovery where approved, retention/DLP scope, storage quota, hub association, regional setting, time zone, and approved integrations.

Validate effective behavior

Test owner/member/visitor/guest access, sharing links, unmanaged device behavior, search and navigation, template artifacts, Team/group membership synchronization, hub association, app access, retention/DLP signals, and audit/change evidence.

Hand off with an owner packet

Provide the URL, purpose, support contact, approved membership/sharing model, label and retention explanation, owner duties, review schedule, prohibited customizations, request path, incident route, and archive/deletion process.

Reconcile and close

Record site/group/Team IDs, created timestamp, automation identity/version, exact policy state, exceptions, test evidence, owner acceptance, next attestation, and failback. Remove failed duplicate sites only after dependency and retention checks.

Templates and automation

Version the desired state and verify the actual state

Site template governance

  • Maintain a catalog of approved templates by business purpose and supported site type.
  • Version the site script JSON, deployment wrapper, dependencies, owner, test tenant, release notes, and retirement date.
  • Test idempotency and partial failure; some actions may succeed before a later action fails.
  • Remember that organization templates can be reapplied and site owners can choose other templates from the experience.
  • Record the template actually applied, not only the template requested.

Automation identity governance

  • Use least-privileged delegated or application permissions and a named owner for every workflow.
  • Inventory app IDs, certificate/secret rotation, managed identities, consent, environment, connector, and site-creation scope.
  • Separate approval from execution so the requester cannot silently approve a sensitive workspace.
  • Protect request parameters from injection or unauthorized policy overrides.
  • Log request ID, approver, input, output IDs, error, retry, and cleanup outcome without storing unnecessary sensitive content.

Current Microsoft behavior: modern SharePoint site templates and site scripts can automate consistent configuration for new and existing sites. Organization templates can be set as defaults, but the template experience cannot simply be disabled and default templates can be changed by the site owner. Treat templates as a controlled baseline plus validation—not an immutable security boundary.

Provisioning baseline

Set protection and lifecycle defaults at creation

Control Decision at provisioning Validation evidence Adjacent governance
Sensitivity and privacy Container label, public/private state, guest access, external sharing, unmanaged-device access, default sharing link, conditional-access authentication context where used Applied label ID/name, effective site/group settings, owner-visible behavior, test user/device result Sensitivity labels for sites and Teams
Owners and membership Minimum owner count, sponsor, member source, guest process, site-admin exception, owner replacement, review frequency Object IDs, owners, group membership source, direct-permission exception, owner acceptance Site owner access recertification
Sharing Tenant/site external-sharing level, guest/Anyone eligibility, default link type and permission, domain restrictions, expiration and request route Effective tenant/site setting, test links, recipient behavior, audit event, documented exception SharePoint and OneDrive sharing security
Information protection Data classification, retention policy/label, record requirement, DLP scope, eDiscovery/hold dependencies, content migration restrictions Policy location/scope, simulation or test evidence, sample event, compliance owner approval Microsoft Purview DLP configuration
Architecture and storage Hub association, region, time zone, URL, storage baseline, versioning, library design, metadata, search, approved apps and integrations Site properties, hub ID, template result, quota, library settings, search/navigation test Storage quota and archiving
Lifecycle Purpose end date, owner attestation, inactivity threshold, group expiration dependency, archive/read-only action, deletion approval, retention check, restore owner Review date, policy scope, owner response, archive state, deletion record, restore test/process Microsoft 365 Groups expiration

Lifecycle is part of provisioning: a group-connected site inherits dependencies across the Microsoft 365 group, Team, mailbox, Planner, and other resources. Deleting and restoring one connected workload can affect the others. Record the authoritative lifecycle and retention path before launch, not when the owner leaves.

Top provisioning risks

Common failures that create sprawl, oversharing, and orphaned content

Treat these as architecture and evidence defects. A successful “site created” response does not prove the workspace is governed.

One creation path governed

SharePoint self-service is restricted, but users, Teams, groups, migration tools, or apps continue creating connected sites outside the request process.

Duplicate workspace

A project receives separate SharePoint, Team, and group workspaces because discovery and architecture decisions were skipped.

Wrong site type

A communication need is placed in a collaboration site or a membership-driven workspace is built with direct SharePoint permissions.

Single or inactive owner

The site launches with one owner, a service account, or a contractor and becomes unmanaged after role or employment changes.

Sensitive name or URL

The visible name, alias, or durable URL exposes a client, matter, investigation, acquisition, health condition, or other confidential subject.

Template assumed immutable

The requested template was only partially applied, later changed, or replaced by a site owner, but no actual-state validation exists.

Label without data decision

A sensitivity label is selected by habit rather than the site’s data, privacy, sharing, device, guest, and regulatory requirements.

Hub mistaken for security

Association is treated as access control even though hub relationships do not grant or remove site permissions.

App creates sites silently

A third-party app or migration identity can create sites broadly, but its app ID, permissions, output inventory, and cleanup process are unknown.

Direct permissions at launch

Users are granted directly to the site or files instead of the approved group/SharePoint role model, creating immediate review and removal gaps.

No lifecycle trigger

The request captures a launch date but no end date, inactivity policy, group expiration, archive condition, or owner attestation.

Failed automation debris

A partial workflow leaves a group, site, Team, alias, hub link, or app permission behind and retry creates duplicates.

Validation, evidence, and rollback

Prove the effective site—not only the request payload

Object relationship

Record site ID/URL/template, Microsoft 365 group ID, Team ID, channel/parent IDs, hub ID, owners, creator, and timestamps. Confirm there is no duplicate alias or orphaned companion object.

Access personas

Test owner, member, visitor, guest, unapproved internal user, unmanaged device, and search/Copilot context as applicable. Validate group membership and direct-permission exceptions.

Sharing behavior

Create only approved test links, verify recipient authentication, expiration/default link behavior, external-domain controls, guest restrictions, and audit events, then revoke test access.

Template and architecture

Verify libraries, lists, metadata, content types, theme, navigation, hub association, home page, time zone, quota, versioning, search, and supported integrations.

Protection and compliance

Confirm label and policy IDs, privacy, unmanaged-device behavior, retention/DLP scope, restricted-access/discovery decision, audit logging, and documented exceptions.

Change and failback

Preserve before/after tenant and workflow configuration, script/template version, created IDs, errors, approval, cleanup command, retention dependencies, and owner notification before rollback.

Deletion is not the first rollback: if the site contains real content, has a connected group/Team, is under retention or hold, or has integrations, assess dependencies before deletion. SharePoint deleted sites are retained for 93 days, but connected Microsoft 365 group resources have different recovery timing. Use a controlled restore and validation procedure.

Related IT Perfection support

Build a practical SharePoint provisioning operating model

IT Perfection can help Orange County and Southern California organizations define site types, request and approval fields, owner standards, naming and URL rules, templates, automation identities, sensitivity and sharing defaults, hub relationships, lifecycle controls, evidence, and support handoffs as part of Microsoft 365 managed services or a focused SharePoint governance project.

Use the Microsoft 365 resource center for the broader operational ecosystem. Learn about the experience behind these guides on Ali Hassani’s profile.

Authoritative Microsoft references

Frequently asked questions

SharePoint site provisioning governance FAQ

Does disabling SharePoint site creation stop Teams and Microsoft 365 group sites?

No. The SharePoint site-creation setting controls several SharePoint, OneDrive, PnP, and REST entry points, but Microsoft 365 groups and Teams can still create connected SharePoint sites. Govern group and Team creation, app/migration creation, and SharePoint self-service as one architecture.

Should every SharePoint site use a Microsoft 365 group?

No. A group-connected team site is appropriate for membership-driven collaboration and related Microsoft 365 services. A communication site is appropriate for broad publishing with a smaller author group. Private and shared Teams channels create specialized channel sites whose membership and lifecycle follow Teams.

Are site templates a security boundary?

No. Templates and site scripts provide a repeatable starting configuration, but actions can fail partially, owners can apply other templates, and later changes can create drift. Validate the effective label, sharing, permissions, libraries, settings, hub, and policy state after provisioning.

What ownership standard should be required?

Use at least two active owners where practical, plus a sponsor and support route. Record the source of membership, owner responsibilities, owner replacement, recertification cadence, sharing accountability, and lifecycle action if ownership becomes noncompliant.

How should a failed provisioning workflow be rolled back?

First inventory every object and action created: site, group, Team, channel, alias, hub association, permissions, app grants, and content. Check retention, hold, and integration dependencies. Remove or reverse only the failed components using the recorded cleanup plan, then verify there is no orphan or duplicate before retry.

Can IT Perfection help design and implement this workflow?

Yes. IT Perfection can assess creation paths, define site patterns and request fields, build owner and naming standards, configure templates and automation controls, align protection and lifecycle defaults, test the effective result, and establish a lightweight evidence and review process.

Make every workspace intentional

Turn SharePoint site creation into a governed, testable lifecycle

IT Perfection can reconcile creation paths, site types, groups and Teams, owners, names and URLs, templates, automation identities, protection defaults, hub architecture, validation evidence, and lifecycle controls—without adding unnecessary plugins or database-heavy workflows.

Schedule a SharePoint provisioning review
Meet Ali Hassani

This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/privacy review, records-management decision, or tenant-specific Microsoft engineering engagement. Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, Microsoft infrastructure, networking, and business technology experience.