If you've read our earlier posts on governance, you know that a governance document is essentially the rulebook for your Microsoft 365 environment. But what should actually be in it? What sections matter, what can you skip, and how detailed does it need to be?
This post focuses specifically on intranet governance — a SharePoint Online communications site used as a company's primary internal channel. That's where governance matters most and where the consequences of getting it wrong are most visible. The principles here apply equally to any SharePoint environment, but the intranet is the best starting point because it touches the most people and carries the most content.
This post covers the baseline — the foundational governance document that every organisation running a SharePoint intranet should have. As your environment matures and you introduce more advanced capabilities — Copilot Studio agents, Microsoft Purview retention and sensitivity labels, extended Teams governance — those areas each deserve their own governance treatment. We'll cover those in a follow-up post.
This post walks through the key sections of a well-structured intranet governance document — drawing on real enterprise implementations — and explains what each section should cover and why it matters.
The Governance Document is Part of a Suite
It's worth noting upfront that a governance document rarely stands alone. In a well-run intranet implementation, it sits alongside a suite of related documents, each serving a different audience:
- Governance Manual — this document. The framework, rules, roles, and processes. Primarily for decision-makers, site owners, and administrators.
- Site Administrator Manual — the technical reference for site owners and SharePoint admins. How to manage templates, configure permissions, update navigation, maintain custom components.
- Content Creator Guide — for contributors and content approvers. How to create pages, which templates to use, how to tag content with metadata, visual identity guidelines, writing style.
- Design and Branding Guide — the visual standards. Approved colour palette, typography, logo usage, web part styling, image guidelines. Ensures the intranet looks consistent regardless of who is publishing content.
Each document references the others. The governance manual sets the policy — the admin manual and content creator guide explain how to implement it in practice. Together they form the complete operating manual for the intranet.
This post focuses on the governance manual specifically.
Who Is This Document For?
Before writing a single word, define the audience. A governance document serves multiple people with very different needs:
- The IT or SharePoint administrator — needs the technical detail: permissions, term store, content types
- Content owners and site owners — need to know their responsibilities and what they can and can't change
- Business stakeholders — need to understand the overall framework and who makes decisions
- New joiners — need a reference for how things work
The document should be written so that each audience can find what's relevant to them without reading the whole thing. A clear index and well-named sections make this possible.
Section 1 — Purpose and Scope
Start with the basics. What is this document for? What environment does it cover? Who owns it and who is responsible for keeping it updated?
This section should define:
- The purpose of the intranet or SharePoint environment
- What content belongs there and what doesn't — content classification
- Who owns the technical infrastructure
- Who owns the content
- Who the authorised users are
Why it matters: Without a clear statement of purpose, people make their own assumptions about what SharePoint is for. One team treats it as a file dump, another as a communications channel, another as a project management tool. The purpose statement sets the direction.
Section 2 — Roles and Responsibilities
This is the heart of the governance document. Define every role clearly — who they are, what they can do, and what they're responsible for.
The standard SharePoint roles to define:
| Role | What they can do |
|---|---|
| SharePoint Administrator | Full tenant access, manages schema, search, custom components |
| Site Collection Administrator | Extended permissions within the site, access to search settings |
| Site Owner | Full control of the site, manages permissions and templates |
| Content Approver | Reviews and publishes content |
| Site Member / Content Contributor | Creates and edits content, cannot publish or change templates |
| Site Visitor | Read-only access |
For each role, go beyond the permission level and document the actual responsibilities — what are they expected to do, how often, and what decisions are theirs to make.
Why it matters: Without clear role definitions, everything lands on the SharePoint admin. Site owners don't know they're responsible for access reviews. Content contributors don't know they need to follow a naming convention. Documenting it removes the ambiguity.
Section 3 — Governance Group
For larger organisations, define the governance body — the group of people responsible for making decisions about the environment. This is typically a cross-functional group that meets regularly (quarterly is common) to review the state of the intranet, approve significant changes, and set direction.
Document:
- Who is in the governance group and what they represent
- How often they meet
- What decisions they're authorised to make
- What requires escalation
For smaller organisations, this might just be one or two people — the SharePoint admin and a business owner. It still needs to be documented. Someone needs to be accountable for decisions.
Why it matters: Without a governance group, nobody owns the big decisions. Structural changes happen ad hoc, inconsistencies accumulate, and there's no forum for raising issues.
Section 4 — Change Management Process
Define how changes to the environment are requested, reviewed, and implemented. Not every change needs a formal process — but distinguishing between minor and major changes is important.
A simple three-tier model works well:
| Category | Examples | Who can approve |
|---|---|---|
| Minor | Template updates, metadata additions, small UI tweaks | Site owner |
| Major | New content types, structural changes, new integrations | SharePoint admin after governance approval |
| Emergency | Critical functionality repairs | SharePoint admin |
Document the request process — how someone submits a change request, who reviews it, what information is needed, and how long it takes.
Why it matters: Without a change process, well-intentioned changes break things. Someone adds a new content type that conflicts with the search schema. Someone reorganises the navigation without telling the team that maintains it. A process doesn't prevent change — it prevents uncoordinated change.
Section 5 — User Access Management
Document the full lifecycle of user access — from the moment someone joins to the moment they leave.
Onboarding
- How access is requested
- Who approves it
- What groups a new user is added to based on their role
- What training or documentation they need before getting access
Offboarding
- What triggers access removal (leaving the organisation, change of role, prolonged absence)
- Who is responsible for removing access
- What happens to content owned by the departing user
- How pending approvals are reassigned
Access reviews
- How frequently access is reviewed (quarterly is the standard recommendation)
- Who is responsible for reviewing their group members
- What happens with inactive accounts
Why it matters: This is the governance section with the most direct security and compliance implications. Unmanaged offboarding leaves former employees with access to sensitive content. Unreviewed permissions accumulate over time into a security risk. A documented process makes this routine rather than reactive.
Section 6 — Security and Permissions
Document the permissions model in detail — which groups exist, what permission levels they have, and what content areas have unique permissions.
A permissions matrix mapping content areas to groups is the most useful format here:
| Content Area | Read | Edit | Full Control |
|---|---|---|---|
| Site Pages | All users | Site Members | Site Owners |
| Policy documents | All users | — | Site Owners |
| HR documents | HR team | HR team | HR Site Owner |
Also document:
- Whether external sharing is enabled or disabled
- What types of sharing links are permitted
- Who can grant external access and under what circumstances
Why it matters: The permissions model is the security model. If it's not documented, nobody knows what the intended state is — making it impossible to audit against or recover to when something goes wrong.
Section 7 — Information Architecture
Document the structural decisions that define how the environment is organised:
- Site structure — which sites exist, how they relate to each other, which are connected to a hub
- Navigation — top-level and second-level navigation nodes
- Folder structure — if folders are used, the agreed hierarchy
- Content types — what content types exist and what metadata each carries
- Term store — the managed taxonomy, including any translations for multilingual environments
- Site columns — the reusable columns that feed into content types
This section is often the most detailed in a governance document and the most important for maintaining consistency over time.
Why it matters: Without documenting the information architecture decisions, they exist only in the heads of the people who made them. When those people leave, the reasoning is lost. New team members make decisions that conflict with the original design without knowing it.
Section 8 — Information Management Lifecycle
Define how content is managed over time — how often it should be reviewed, what happens when it's outdated, and when it should be archived or deleted.
A content review schedule by content type is the most practical format:
| Content Type | Review Frequency | Action When Outdated |
|---|---|---|
| Policies | Every 3 years | Archive or replace |
| Process manuals | Every 2 years | Archive or replace |
| News articles | No review needed | Archive after 1 year |
| General pages | Annually | Delete or archive |
Why it matters: Outdated content is one of the most common intranet problems. Users stop trusting search results when they return obsolete pages. A review schedule makes content management a routine responsibility rather than a crisis when the intranet becomes visibly stale.
A Note on Copilot — Baseline Governance Comes First
If your organisation is using or planning to use Microsoft Copilot — whether Microsoft 365 Copilot or Copilot Studio agents — your intranet governance document should include a baseline position on it even if the detail is light.
At minimum, document:
- Whether Copilot is enabled on the intranet site and for which users
- Who can create Copilot Studio agents that interact with intranet content — this should require explicit approval, not be open to anyone
- Which sites and content Copilot can access — Copilot respects SharePoint permissions, so if your permissions model is clean, Copilot will surface only what users are already allowed to see. If your permissions are messy, Copilot will surface things you didn't intend.
- The approval process for new Copilot agents — a clear statement that deploying an agent against intranet content requires governance group sign-off
This is the baseline. Copilot governance goes much deeper — data processing implications, sensitivity labels, DLP policies, environment strategy for Copilot Studio — but those belong in a dedicated document once your intranet governance foundation is solid.
👉 See our follow-up post: Copilot in SharePoint — The Governance Decisions Your Organisation Needs to Make Before June 2026
What You Can Leave Out for Smaller Organisations
Not every organisation needs all of these sections at the same level of detail. For a company with 20–50 employees:
- Governance group can be one person — just name them and document their responsibilities
- Change management can be a simple email approval process rather than a formal request system
- Information architecture might be two or three sites rather than a complex hub structure
- Term store might not exist at all if Choice columns are sufficient
The goal is not a 30-page document — it's a document that answers the questions people will actually have. For a small company, four or five sections covering roles, permissions, access management, and content review expectations might be entirely sufficient.
The Template
A governance document is easier to write when you start from a structure. Download our simplified Microsoft 365 Governance Template — a fillable document covering the core sections outlined above, with guidance notes explaining what to include in each section.