Microsoft Teams Governance Policy Template for Australian Organisations

A Microsoft Teams governance policy defines the rules that control how teams are created, named, managed, and retired in your organisation — and it is the foundation of a compliant Microsoft 365 environment for any Australian organisation handling personal or sensitive information.

Without a policy, most organisations discover they have hundreds of teams with no clear ownership, inconsistent naming, sensitive files stored without classification, and external guests who still have access long after a project ended. Microsoft 365 Copilot makes this problem urgent: without governance, Copilot will happily summarise content from all of those ungoverned locations on behalf of any user who asks.

This article provides a practical policy template structured around six governance domains, with Australian-specific compliance considerations woven throughout. Use it as a starting point and adapt it to your organisation's risk appetite and operational context.

Before you draft your policy, a free SharePoint and Teams Governance Assessment will give you a baseline view of where your current environment stands against best practice — so you are writing policy to close real gaps, not imagined ones.

Updated 8 October 2026: Microsoft is retiring Restricted SharePoint Search, so this post now points to Restricted Content Discovery and SharePoint Advanced Management instead.

Why Australian Organisations Need a Written Teams Governance Policy

Many Australian organisations operate Microsoft Teams under an implicit understanding that "IT manages it" — but IT cannot make governance decisions about business data. Governance requires business owners to make explicit decisions about classification, retention, and access, with IT implementing those decisions as technical controls.

The Privacy Act 1988 and Australian Privacy Principles place obligations on organisations to protect personal information and ensure it is not retained longer than necessary for the purpose for which it was collected. Teams conversations, meeting recordings, files, and channel posts frequently contain personal information — names, contact details, HR discussions, customer data — and without a governance policy, that information accumulates indefinitely with no accountability.

The Australian Signals Directorate's Essential Eight controls also have relevance here: application control, restricting administrative privileges, and patching are all supported by a well-governed Teams environment where the number of owners, the scope of external access, and the lifecycle of content are under active management.

Microsoft Teams Governance Policy Template

The following template is structured for direct adaptation. Replace bracketed placeholders with your organisation's specifics.

Policy Statement

[Organisation Name] requires that all use of Microsoft Teams comply with this governance policy to protect information assets, support compliance with the Privacy Act 1988, and maintain an organised and secure collaboration environment. This policy applies to all staff, contractors, and external parties accessing Microsoft Teams on behalf of [Organisation Name].

1. Team Creation

Who can create teams:

Only authorised team requestors — members of the [Teams Provisioning Security Group] in Entra ID — may create new Microsoft Teams. All other users must submit a request through [insert request process: e.g., ServiceNow form, Teams app, IT helpdesk].

What approvals are required:

All team creation requests must include:

• Business purpose of the team
• Proposed team name (compliant with naming convention below)
• Nominated primary and secondary owner (must be permanent staff, not contractors)
• Estimated number of members
• Whether external guests will be invited
• Classification level (see Section 3)
• Expected team lifecycle (project-based with end date, or ongoing operational)

Provisioning SLA:

Standard requests are fulfilled within [2 business days]. Requests involving external guest access require manager approval and are fulfilled within [3 business days].

Rationale:

Uncontrolled team creation is the primary driver of governance debt in Microsoft 365 environments. Centralising creation allows the organisation to apply naming conventions, classification, and lifecycle settings at provisioning time rather than retrospectively.

2. Naming Conventions

All team names must follow this format:

[PREFIX]-[BusinessUnit]-[TeamPurpose]-[Year if project-based]

Approved prefixes:

Examples:

• PROJ-Marketing-WebsiteRelaunch-2026
• OPS-Finance-AccountsPayable
• CONF-HR-ExecutiveReviews
• EXT-Legal-MatterName2026

Prohibited in team names:

• Individual employee names or initials
• Client names (use a matter or project code instead)
• Personal information of any kind
• Classification labels that duplicate the prefix (e.g., do not add "INTERNAL" when using OPS)

Technical enforcement:

A naming policy will be configured in Entra ID to enforce the prefix requirement. Teams created without the approved prefix will be rejected at provisioning. Existing teams that do not comply will be flagged during the next lifecycle review.

3. Classification and Sensitivity Labels

Every team must be assigned a sensitivity label at creation. The sensitivity label determines what features are available and how content within the team is protected.

Applying sensitivity labels:

Sensitivity labels are selected during the provisioning request process. The label is applied to the underlying Microsoft 365 Group and propagates to the associated SharePoint site and Teams environment.

If a team's content evolves to require a higher classification, the team owner must submit a reclassification request through [insert process]. Teams cannot be downgraded in classification without [IT Security / Privacy Officer] approval.

Relevance to Copilot:

The SharePoint sites behind Teams classified as Highly Confidential should have Restricted Content Discovery applied, so their content stays out of organisation-wide search and Copilot responses, and Restricted Access Control where only a defined group should have access. Pair this with sensitivity labels and DLP for Copilot. See the governance guide on Restricted Content Discovery and choosing which sites to protect for the technical configuration that supports this.

4. Ownership and Membership

Ownership requirements:

Every team must have a minimum of two owners at all times. Both owners must be permanent employees of [Organisation Name]. Contractors may not serve as team owners.

Owners are responsible for:

• Approving membership requests
• Managing guest access
• Responding to lifecycle review prompts
• Ensuring team content remains appropriately classified
• Archiving or deleting the team when it is no longer needed

If an owner leaves the organisation:

When a team owner's account is deactivated, [IT/Helpdesk] will notify the remaining owner and the departing owner's manager within [2 business days]. A replacement owner must be nominated within [5 business days]. Teams with no active owners will be flagged for escalation to the business unit manager.

Membership hygiene:

Owners must review team membership at least every [6 months] and remove members who no longer require access. Membership reviews are prompted by the lifecycle review process described in Section 5.

Guest access:

External guests may only be added to teams with the EXT prefix and a classification of General or Confidential. Guests must be added using their primary business email address. Personal email addresses (gmail.com, hotmail.com, etc.) are prohibited unless explicitly approved by [IT Security].

All guest access expires after [90 days] and must be renewed by the team owner if still required. The [Entra ID Guest Access Review] process will send renewal prompts to owners automatically.

5. Lifecycle Management

Team lifecycle stages:

1. Active — Team is in regular use and owner has confirmed it is needed
2. Inactive — No activity for [60 days]; owner receives a review prompt
3. Review — Owner has 30 days to confirm the team is still needed or archive it
4. Archived — Team is read-only; content is preserved but no new messages or files can be added
5. Deleted — Team and all associated content is soft-deleted; restored within 30 days if needed; permanently deleted after 30 days

Expiry policy:

An Entra ID Groups expiry policy is configured with a [180-day] renewal period. Owners receive automated renewal prompts at 30 days, 15 days, and 1 day before expiry. If no action is taken, the team enters the archived state automatically.

Project teams:

Teams created with the PROJ prefix must include an expected end date in the provisioning request. The team will enter the lifecycle review process 30 days before the specified end date.

Archiving vs deletion:

Teams should be archived (not deleted) when their content may be required for compliance, audit, or legal hold purposes. Check with your [Records Manager / Privacy Officer] before deleting any team that handled personal information or was involved in a significant project.

Retention:

Teams content is subject to [Organisation Name]'s retention schedule. Apply Microsoft 365 retention labels or retention policies to ensure Teams messages and files are retained for the required period and then disposed of in accordance with the [Records Management Policy].

6. External Collaboration

External collaboration through Microsoft Teams carries additional risk because it extends your information boundary to parties you do not control. The following rules apply to all external collaboration via Teams:

Before inviting external guests:

• Confirm that guest access is appropriate for the team's classification (see Section 3)
• Obtain manager approval for the business need
• Verify the guest's identity and organisation before sending the invitation
• Ensure the team does not contain content that is inappropriate for external access

What guests can access:

Guests invited to a Teams channel can view and participate in channel conversations, access files shared within the channel, and attend meetings. They cannot access content in channels to which they have not been explicitly added.

Shared Channels:

Shared Channels (which allow external Teams users to collaborate without switching tenants) require separate approval from [IT Security]. Shared Channels are disabled by default in [Organisation Name]'s tenant and must be enabled on a case-by-case basis.

Data residency:

All content created within Microsoft Teams is stored in the [Organisation Name] Microsoft 365 tenant, hosted in [Australia / a geographic region you have confirmed]. Verify your tenant's data residency configuration in the Microsoft 365 Admin Centre under Settings > Org settings > Organisation profile > Data location.

Implementing Technical Controls to Enforce This Policy

A governance policy without technical enforcement is aspirational at best. The following controls should be configured to support each section of this policy:

Restrict team creation: Use Entra ID group creation restriction to limit team creation to the provisioning security group. This is configured via PowerShell using the Set-AzureADDirectorySetting cmdlet or through the Entra admin centre.

Naming policy: Configure a Prefix/Suffix naming policy in Entra ID under Groups > Naming policy. The prefix requirement will be enforced at team creation time.

Sensitivity labels: Configure sensitivity labels in the Microsoft Purview compliance portal. Publish the labels to all users and configure the Teams label settings to control guest access and external sharing per label.

Expiry policy: Configure group expiry in Entra ID under Groups > Expiration. Set the expiry period and ensure the notification email address is monitored.

Guest access review: Configure access reviews in Entra ID Identity Governance. Schedule quarterly reviews for all teams with guest members, with owners as reviewers.

SharePoint Advanced Management: Run data access governance reports and site access reviews across your Teams-connected SharePoint sites. Apply Restricted Content Discovery to sensitive sites while access is reviewed, and use Restricted Access Control to limit a site to a named group. Treat Restricted Content Discovery as temporary and remove it once access is remediated.

Rolling Out the Policy

A policy that staff do not know about will not be followed. Plan your rollout in three phases:

Phase 1 — Communication (weeks 1 to 2): Brief business unit managers on the policy. Send an all-staff communication explaining that new team creation will require a request process. Publish the policy on the intranet.

Phase 2 — Technical enablement (weeks 3 to 4): Enable the Entra ID group creation restriction, naming policy, and expiry settings. Run an initial audit of existing teams and identify those that require reclassification, additional owners, or immediate archiving.

Phase 3 — Remediation (weeks 5 to 12): Work through the existing team audit systematically. Contact owners of non-compliant teams and set a deadline for remediation. Archive teams with no active owners and escalate to business unit managers where needed.

Maintaining the Policy

Review this policy annually or whenever a significant change occurs in your Microsoft 365 environment — for example, when enabling Microsoft 365 Copilot, adopting Shared Channels, or onboarding a new category of external partner.

The [IT Security / Privacy Officer] is responsible for maintaining this policy and ensuring technical controls remain aligned with policy intent.

If you are not sure how well your current Teams environment aligns with governance best practice, start with a free SharePoint and Teams Governance Assessment. The assessment maps your current configuration against the six domains covered in this policy and gives you a prioritised view of what to address first.