Teams Governance — Why Most Enterprises Get It Wrong

By Suvankar Chakraborty | Principal Engineer — IAM, Modern Workplace Management & IT Operations

The Collaboration Platform That Became a Governance Nightmare

Microsoft Teams was deployed at extraordinary speed across the enterprise world. In most organisations I know, the deployment timeline went something like this: March 2020, global pandemic, remote work mandate, Teams switched on, everyone told to use it, governance deferred because there was no time.

Five years later, the governance that was deferred in 2020 has still not been implemented in most of those environments.

The result is predictable and consistent across industries: Teams sprawl at industrial scale. Hundreds of Teams that nobody owns. Channels for projects that ended three years ago. Guest users from partnerships that dissolved. Sensitive conversations in channels that include contractors who should not have visibility. Files shared in Teams chat — bypassing SharePoint governance entirely — on devices with no management policy. Meeting recordings stored in OneDrive folders that anyone with a link can access. Bot integrations that have permissions to read your Teams messages and access your calendar, approved by a user who clicked through an OAuth consent screen without reading it.

In 13+ years of enterprise IAM and IT operations work, Teams governance has become one of the most consistently mismanaged areas of Microsoft 365. Not because it is technically difficult — the controls Microsoft provides are comprehensive. But because Teams sits at the intersection of IT, security, compliance, and the organisational culture of collaboration, and that intersection is where governance programmes go to die.

This article is about why enterprises get Teams governance wrong, and what getting it right actually looks like — in specific, actionable, implementable terms.

---

Why Teams Is a Governance Problem Unlike Any Other M365 Workload

To understand the governance challenge, you need to understand what Microsoft Teams actually is architecturally — because it is far more complex than it appears to end users.

When a user creates a Microsoft Team, they are not just creating a chat room. They are creating:

• A Microsoft 365 Group — the identity and membership container
• A SharePoint site — the document storage backend for the Team's files tab and channels
• A SharePoint document library — one per channel, automatically created
• An Exchange Online shared mailbox — for group email and calendar
• A OneNote notebook — automatically created in the SharePoint site
• Optionally, a Planner plan, a Stream channel, a Power BI workspace, and various third-party app integrations

One "create a Team" action creates six or more objects across four Microsoft 365 workloads. When the Team is eventually decommissioned — if it is ever decommissioned — all of these objects need to be managed. If Teams sprawl is uncontrolled, the sprawl cascades across SharePoint, Exchange, and Entra ID simultaneously.

This is why Teams governance is not just a Teams problem. It is an M365 governance problem that manifests through Teams.

---

The Five Ways Enterprises Get Teams Governance Wrong

Wrong 1: They let any user create a Team

The most fundamental governance failure in most enterprise Teams deployments is the absence of Team creation controls.

By default, any Microsoft 365 user can create a Team. The UX is frictionless — click the + button, fill in a name, click Create. Thirty seconds later, a new Team exists with a SharePoint site, a mailbox, and a notebook, with the creator as the sole owner.

At 5,000 users, even if 10% of your users create one Team each, you have 500 Teams inside a year. Many of these Teams will have:

• A single owner — the person who created it, who will eventually leave the company
• No documented purpose
• No defined membership criteria
• No planned decommission date
• No sensitivity classification

In the environments I assess, uncontrolled Team creation is almost always the root cause of the sprawl problem. Everything else — orphaned Teams, stale channels, ungoverned guest access — flows from this original failure.

What getting it right looks like:

Restrict Team creation to a defined population. Navigate to Entra admin center → Groups → General settings and restrict Microsoft 365 Group creation (which underlies Teams) to a specific security group. Create a Team creation request process — a simple form, a lightweight approval, an IT team that provisions the Team with standard governance settings applied.

This does not mean locking down collaboration. It means adding a lightweight process that ensures every Team starts with:

• A documented business purpose
• At least two designated owners (never one — single owner is a governance failure waiting to happen)
• A defined initial membership
• A sensitivity label applied at creation
• A planned review date

The overhead of this process is measured in minutes. The governance benefit is measured in months of remediation avoided.

---

Wrong 2: They ignore the Teams lifecycle — teams never die

A Team created for a project that ran from January to June will, without lifecycle controls, still exist in December. And next December. And the December after that. Indefinitely. With the same channels, the same files, the same membership, the same guest users — long after every legitimate reason for the Team's existence has passed.

Multiply this by hundreds of Teams and you have a sprawl problem that is not just a hygiene issue. It is a security and compliance issue. Sensitive project data in a completed-project Team is still accessible to everyone who was a member — including contractors, partners, and former employees whose accounts were not promptly disabled. That data can still be downloaded, forwarded, and exfiltrated.

The scale of the problem:

Microsoft's own research has found that in enterprise Teams deployments without lifecycle controls, more than 50% of Teams are inactive (no activity in 90+ days) within two years of deployment. In larger enterprises I have assessed, the figure is often higher.

What getting it right looks like:

Implement Microsoft 365 Group expiration policy in Entra ID:

Navigate to Entra admin center → Groups → Expiration:

• Group lifetime: 180 days (Teams created for long-running functions can be renewed; project Teams will naturally expire)
• Automatic renewal: Groups with activity (messages, file access, meetings) are automatically renewed — no owner action required for active Teams
• Groups requiring renewal: Inactive groups send renewal notifications to all owners. If no owner confirms renewal within the notification window, the group is deleted after a 30-day grace period

This policy means active Teams continue without interruption. Inactive Teams surface to owners for a conscious keep-or-delete decision. Teams whose owners have left the company are flagged through the orphaned-owner process (covered below) before deletion.

Additionally, implement a Teams lifecycle review as part of your quarterly IT governance cadence — review all Teams older than 12 months, confirm active ownership, confirm continued business purpose, archive or delete Teams that have run their course.

Teams archiving vs deletion:

Not all completed-project Teams should be deleted. Some contain content that must be retained for compliance, legal, or business reference purposes. Microsoft Teams supports archiving — a Team can be archived, making it read-only. Content is preserved in SharePoint, accessible to current members for reference, but no new messages or files can be added. Archived Teams do not count toward active governance overhead but their content remains governed.

Archive Teams whose projects have completed but whose content has retention value. Delete Teams whose content has no ongoing value. Never leave Teams in an active, unarchived state indefinitely without governance.

---

Wrong 3: They do not govern guest access

Guest access in Teams — the ability to add external users (partners, contractors, clients, suppliers) to Teams channels — is one of the most valuable enterprise collaboration features Microsoft 365 offers. It is also one of the most consistently ungoverned.

The default configuration in most tenants allows Team owners to invite any external user to their Team. The guest is added to the Microsoft 365 Group, given access to the Team's SharePoint site and its entire file history, and can participate in all channels the owner adds them to. The guest account is created in Entra ID. There is typically no approval process, no time limit, no periodic review, and no automatic decommission.

What actually happens in practice:

A project manager invites a supplier's representative to a Teams channel to collaborate on a procurement project. The supplier representative gets access to the Team, the associated SharePoint site, and all the files in it — including files that predate the current project and were never intended for external visibility.

The project ends six months later. The supplier representative's guest account remains active. They still have access to the Team and all its content. Nobody removes them because there is no process to remove them. Their account sits in Entra ID, returning to the Team and its files whenever they choose.

This scenario plays out thousands of times in medium and large enterprises. The cumulative external access exposure is significant.

What getting it right looks like:

Governance layer 1 — Restrict who can invite guests:
Navigate to Entra admin center → External Identities → External collaboration settings:

• Guest invite settings: "Only users assigned to specific admin roles can invite guest users" (most restrictive) or "Member users and users assigned to specific admin roles can invite guest users"
• Do not allow: "Anyone in the organization (including guests) can invite"

Governance layer 2 — Configure what guests can do in Teams:
Navigate to Teams admin center → Users → Guest access:
Configure guest capabilities. My recommended baseline:

• Allow calling: Off (unless required)
• Allow meeting video: On (needed for genuine collaboration)
• Allow screen sharing: Off (guests should not share their screens in your tenant without specific justification)
• Allow guest user to edit/delete sent messages: On (normal collaboration)
• Allow guests to create/update channels: Off (guests should participate, not administer)
• Allow guests to delete channels: Off
• Allow private calls: Off

Governance layer 3 — Quarterly access reviews for all guests:
Every guest account in your tenant should be subject to quarterly access review in Entra ID Identity Governance. The review is sent to the sponsor (the Team owner who invited the guest). If the sponsor does not actively confirm the guest still needs access, access is automatically revoked.

Governance layer 4 — Guest account expiry:
Configure guest accounts to expire after 12 months by default, requiring recertification. Navigate to Entra admin center → External Identities → External collaboration settings → Collaboration restrictions — set external user collaboration expiry.

Governance layer 5 — Cross-tenant access settings (Entra ID B2B direct connect):
For regular partner organisations with whom you have ongoing collaboration, configure Cross-tenant access settings in Entra ID to create a managed B2B relationship rather than ad-hoc guest invitations. This provides better trust, better governance, and better user experience than individual guest accounts.

---

Wrong 4: They do not manage external access and federation

External access (sometimes called federation) is distinct from guest access. External access allows Teams users in your organisation to communicate with Teams users in other organisations — find them, message them, start calls — without those external users being guests in your tenant.

By default, Teams external access is enabled for all Teams users to communicate with all other Teams organisations globally. This means your employees can communicate directly with any person in any other Microsoft Teams tenant — including tenants with no security controls, no governance, and no verification of who their users are.

The risk this creates is primarily social engineering and data exfiltration through external Teams messaging — attackers who create a Microsoft 365 tenant, add their attack persona as a user, and reach out to your employees via Teams external access, impersonating vendors, IT support, or executives.

What getting it right looks like:

Navigate to Teams admin center → Users → External access:

Option 1 — Allow only specific domains (recommended for most enterprises):

• External access: Off for all external domains
• Add explicit allow-list of specific partner and supplier domains you regularly collaborate with
• All other domains: blocked

This ensures your employees can only communicate externally via Teams with users from domains you have explicitly approved. Any domain not on the allow-list cannot reach your users directly.

Option 2 — Block high-risk domains (minimum baseline):
If full domain allow-listing is not operationally feasible, at minimum:

• Block personal email domains that have been registered as Microsoft 365 tenants (common in phishing)
• Block consumer-oriented domains
• Enable Microsoft Teams threat intelligence alerts for suspicious external communication patterns

Separate from federation: configure Teams external access for Teams to Skype consumer:
Disable Teams-to-Skype consumer communication unless there is a specific business requirement — this exposes your users to the entire Skype consumer user base.

---

Wrong 5: They let third-party apps run ungoverned

The Microsoft Teams app store contains thousands of third-party applications — bots, tabs, connectors, and message extensions — that users can add to Teams channels and personal apps. Each of these applications requests OAuth permissions to access your Microsoft 365 data when installed.

A bot added to a Teams channel may request permissions to:

• Read all Teams messages in the channels it is added to
• Read user profiles
• Send messages on behalf of users
• Access files in the associated SharePoint sites
• Read calendar information

Users consent to these permissions with a single click, without understanding what they are agreeing to. The permissions are granted at the Microsoft 365 tenant level for the installing user's scope, but in many cases extend to data beyond what the user reasonably intends.

The specific risks:

Data exfiltration through apps: A malicious or compromised third-party app with read permissions on Teams messages can access and exfiltrate every conversation in every channel it has been added to.

Credential harvesting through malicious tabs: Malicious Teams tab applications can render phishing pages within the familiar Teams interface, making credential harvesting significantly more effective.

Supply chain compromise through legitimate apps: Even legitimate, well-intentioned apps can become attack vectors if the app vendor is compromised. In 2021 and 2022, several widely-used SaaS applications experienced supply chain compromises that affected their Microsoft 365 integrations.

Shadow IT through apps: Business users add productivity apps to Teams without IT visibility — each app creating a new data integration that bypasses IT security review.

What getting it right looks like:

Navigate to Teams admin center → Teams apps → Permission policies:

Create a global app permission policy that blocks all third-party apps by default:

• Microsoft apps: Allow all (or allow specific)
• Third-party apps: Block all apps
• Custom apps: Block all apps (unless you have a managed custom app programme)

Create an approved app catalogue:
Establish a formal app review process. For each third-party app requested by business users:

1. Review the OAuth permissions requested
2. Assess the vendor's security posture (SOC 2 report, privacy policy, data processing terms)
3. Evaluate business justification vs. risk
4. Approve or decline
5. Add approved apps to a permitted app list and publish via specific app permission policies to the users who need them

Apply elevated app policies for privileged users:
Create an additional, more restrictive permission policy for IT administrators and security personnel — they should not be running unreviewed third-party apps in their Teams environment regardless of general policy.

Audit existing app installations:
Navigate to Teams admin center → Teams apps → Usage reports to see which apps are currently installed across your tenant and who installed them. For each third-party app currently in use that has not gone through formal approval, conduct a rapid review — approve and formalise, or remove.

Configure admin consent for app permissions:
Navigate to Entra admin center → Applications → Enterprise applications → Consent and permissions → User consent settings — set to require admin consent for app permissions, preventing users from self-approving OAuth permissions for new apps.

---

The Critical Controls Most Teams Deployments Are Missing

Beyond the five failure modes above, there are specific technical controls that provide significant governance value and are absent from most enterprise Teams deployments.

Control 1: Teams channel type governance — Standard vs Private vs Shared

Teams has three channel types with very different permission behaviours:

Standard channels — accessible to all Team members. This is the default and appropriate for most collaboration.

Private channels — accessible only to a subset of Team members explicitly added to the channel. Private channels have their own SharePoint site collection — separate from the Team's main site. This means they have their own independent permissions, storage, and governance requirements. They are also not visible to Team owners unless the owner is a member of the private channel — a fact that surprises many IT administrators.

Shared channels — Teams' newest channel type, which allows adding external users from other organisations directly into a channel without making them guests in your Entra ID tenant. Shared channels use B2B direct connect.

Governance implications:

Private channels create SharePoint sites that your standard SharePoint audit tooling may miss because they are separate site collections. Include private channel sites explicitly in your SharePoint governance programme.

Shared channels bypass the guest account creation process — external users in shared channels do not have guest accounts in your directory. You cannot govern them through Entra ID guest access reviews. You must govern them through Cross-tenant access settings.

Recommendation: Define a clear policy for when each channel type is appropriate. Many organisations over-use private channels, creating unnecessary complexity. If information needs to be restricted, restructuring team membership is often cleaner than proliferating private channels.

Control 2: Meeting policy governance — recording, transcription, and retention

Teams meetings generate recordings and transcripts that contain significant amounts of potentially sensitive conversational content. The governance of meeting recordings is one of the most consistently overlooked areas of Teams administration.

Default behaviour (ungoverned):

• Any Teams meeting participant can start a recording
• Recordings are stored in the recorder's OneDrive (for Meet Now meetings) or in the Teams channel's SharePoint library (for channel meetings)
• Recordings have a default expiry of 120 days (configurable) or are kept indefinitely
• AI-generated transcripts are enabled by default and stored alongside recordings
• Meeting chat is preserved

Governance implications:

A board meeting recorded by any participant, stored in that participant's OneDrive with a sharing link, with no expiry and an AI transcript of every word spoken — is an extremely sensitive data governance risk. Meeting recordings of strategy sessions, M&A discussions, personnel decisions, and legal consultations create compliance obligations that most organisations have not mapped.

What getting it right looks like:

Navigate to Teams admin center → Meetings → Meeting policies:

Configure recording controls:

• Who can record: Configure to "Organizer and co-organizers only" for sensitive meeting types — prevents participants from initiating unauthorised recordings
• Cloud recording: Disable for guest and external participant meetings unless explicitly required
• Transcription: Align with your data classification and regional legal requirements — some jurisdictions require explicit consent for transcription, which the default Teams prompt may not satisfy for all meeting types
• Recording expiry: Set a default recording expiry appropriate to your retention policy — the default 120 days is reasonable for most meeting types; extend for formal business meetings with retention requirements
• Explicit recording storage policy: For channel meetings containing sensitive content, configure recordings to a governed SharePoint location (not individual OneDrives) and apply appropriate sensitivity labels

Create tiered meeting policies:

• Standard users: recording enabled, expiry 120 days
• Executive users: recording disabled by default (must be explicitly enabled per meeting), transcription opt-in
• Guest-invited meetings: recording disabled by default

Control 3: Information Barriers — mandatory for regulated industries

Information Barriers in Microsoft Purview prevent specific groups of users from communicating with or seeing content from other specific groups. This is a compliance requirement for organisations with information segregation mandates — financial services firms separating equity research from investment banking, pharmaceutical companies separating clinical trial teams from commercial teams, legal firms separating clients with conflicting interests.

Without Information Barriers, Teams allows any user to search for and communicate with any other user in the tenant — including users in departments that regulatory requirements mandate be separated.

Implementation overview:

Information Barriers require Entra ID P1 licences and Microsoft Purview Information Protection licences (included in E5 or available as add-ons).

Define barrier segments based on your organisational structure and compliance requirements:

# Define segments
New-InformationBarrierSegment -Name "EquityResearch" -UserGroupFilter "Department -eq 'Equity Research'"
New-InformationBarrierSegment -Name "InvestmentBanking" -UserGroupFilter "Department -eq 'Investment Banking'"

# Define policies preventing communication between segments
New-InformationBarrierPolicy -Name "EquityResearch-IB-Policy" `
    -AssignedSegment "EquityResearch" `
    -SegmentsBlocked "InvestmentBanking" `
    -State Active

# Apply the policies
Start-InformationBarrierPoliciesApplication

For pharma, manufacturing, and FMCG enterprises without formal regulatory information segregation requirements, Information Barriers are not typically necessary. For financial services, legal, or certain defence and public sector contexts — they are a compliance mandatory.

Control 4: Sensitivity labels on Teams and their associated sites

Microsoft Purview sensitivity labels can be applied at the Team level (not just to individual documents) — controlling the privacy of the Team (private vs public), controlling whether guests can be added, and controlling the sensitivity classification of all content in the Team's SharePoint site.

A Team labelled "Highly Confidential" can be automatically configured to:

• Be private (not discoverable in the Teams directory)
• Block guest access
• Apply Conditional Access restrictions (managed device only) to its SharePoint content
• Prevent download of its content on unmanaged devices

Implement label-driven Team governance:

Navigate to Microsoft Purview compliance portal → Information protection → Labels:

For each sensitivity label you want to use on Teams:

• Enable the label for Groups and Sites scope (in addition to Files and Emails)
• Configure privacy setting (Private vs Public)
• Configure external user access (block guests for Confidential and above)
• Configure conditional access (require managed device for Highly Confidential)

When a new Team is created, require a sensitivity label selection. The label selection drives the Team's governance configuration automatically — no manual configuration required per Team.

This is the most scalable governance approach for Teams: encode your governance requirements into labels, apply labels at Team creation, let the label enforce the controls automatically.

---

Building the Teams Governance Framework — The Complete Architecture

Drawing together all the above controls, here is the complete Teams governance framework architecture for a 5,000-user enterprise:

Pillar 1: Provisioning governance

Control	Configuration	Outcome
Team creation restriction	Microsoft 365 Group creation limited to approved users	No ungoverned Teams created
Mandatory Team metadata	Name, purpose, owner(s), sensitivity label required at creation	Every Team has documented context
Dual ownership requirement	Minimum 2 owners enforced at provisioning	No single-owner Teams
Sensitivity label at creation	Label required, drives privacy/guest/Conditional Access settings	Security controls applied from day one

Pillar 2: Lifecycle governance

Control	Configuration	Outcome
Group expiration policy	180-day lifetime, auto-renewal for active Teams	Inactive Teams surface for owner review
Orphaned Team detection	Monthly report: Teams with no active owner	Ownership gaps identified and remediated
Quarterly lifecycle review	IT governance review of all Teams >12 months old	Conscious keep/archive/delete decisions
Archiving policy	Completed-project Teams archived, not deleted	Content preserved without active governance overhead

Pillar 3: Access governance

Control	Configuration	Outcome
Guest invite restrictions	Only specific roles can invite guests	No ungoverned external invitations
Guest access configuration	Scoped capabilities — no calling, no channel admin	Guests can collaborate, not administer
Guest access reviews	Quarterly, sponsor-based, auto-revoke on no response	No stale guest accumulation
External access (federation)	Domain allow-list only	External Teams communication restricted to approved organisations
Cross-tenant access settings	Configured for regular partner tenants	Managed B2B relationships

Pillar 4: Content and data governance

Control	Configuration	Outcome
Sensitivity labels on Teams	Configured for Groups and Sites scope	Privacy and access controls driven by classification
DLP policies in Teams	Applied to Teams messages and files	Sensitive data blocked from inappropriate sharing in Teams
Meeting recording policy	Tiered by user type and meeting sensitivity	Recording governed, not ungoverned
Retention policies for Teams messages	Configured in Purview	Compliance retention requirements met
Information Barriers	Configured for regulated industries	Mandatory information segregation enforced

Pillar 5: App governance

Control	Configuration	Outcome
Third-party app default	Block all third-party apps globally	No ungoverned app installations
Approved app catalogue	Formal review and approval process	Only reviewed apps available
Admin consent requirement	User consent blocked, admin consent required	No unreviewed OAuth permissions granted
App usage monitoring	Monthly review of app installation reports	Shadow IT detected and addressed

---

The Governance Operating Model — Who Owns What

A governance framework without an operating model is a document, not a programme. Define ownership clearly:

IT Administration team owns:

• Team provisioning process and tooling
• Technical configuration of all Teams admin policies
• Monitoring of governance metrics and reports
• Remediation of technical governance findings

Information Security team owns:

• Approval of guest access policy exceptions
• Third-party app security review and approval process
• Information Barriers configuration (where applicable)
• Security incident response for Teams-related events

Business unit managers own:

• Requesting new Teams through the provisioning process
• Maintaining active ownership of their Teams
• Responding to lifecycle review notifications (renew or archive?)
• Managing their Team's membership and channel structure

Compliance / Legal team owns:

• Retention policy requirements
• Information Barriers requirements
• Legal hold processes for Teams content
• GDPR obligations related to external sharing

The key principle: Governance decisions that require business judgement (is this Team still needed?) should be owned by the business. Governance controls that require technical implementation (how is the policy configured?) should be owned by IT. Compliance requirements should be articulated by compliance and implemented by IT. These ownerships should not collapse into IT owning everything — it does not scale.

---

Measuring Teams Governance — The Metrics That Matter

You cannot manage what you do not measure. Track these metrics monthly and report them to leadership quarterly:

Metric	Target	How to measure
Teams with two or more active owners	>95%	Teams admin center → Teams → filter by owner count
Inactive Teams (>90 days no activity)	<5% of total	Teams admin center → Usage reports
Guest accounts with no sign-in in 90+ days	<2% of total guests	Microsoft Graph → User sign-in activity
Teams without sensitivity label	0%	Teams admin center → Teams → filter by sensitivity
Third-party apps not in approved catalogue	0	Teams admin center → Teams apps → App usage
Access reviews completed on time	100%	Entra ID → Identity Governance → Access reviews
Teams with a single owner	0%	Teams admin center + PowerShell

The first time you run these metrics, the numbers will be uncomfortable. That is the point. Track improvement over the subsequent quarters — the metrics should improve consistently as governance controls take effect.

---

The Conversation Nobody Wants to Have: Balancing Governance and Collaboration Culture

I want to address this directly because it is the real reason Teams governance fails in most organisations.

IT teams frequently present governance controls as restrictions on collaboration. Business users experience them as friction. The conflict that results produces governance rollbacks — controls that were implemented are removed when business users complain loudly enough. The governance programme collapses under political pressure.

This framing is wrong, and it sets up the wrong conversation.

The correct framing:

Good Teams governance does not make collaboration harder. It makes collaboration sustainable. The alternatives are:

• Finding in a regulatory audit that your Teams environment contains years of ungoverned sensitive content with external access
• Discovering in a security incident that a former employee or former guest account was accessing your Teams content for months after their legitimate access should have ended
• Being unable to respond to a legal hold or eDiscovery request because your Teams content is unstructured, unclassified, and unretained
• Having a sensitive project discussion exposed through a compromised third-party app that a business user installed without security review

These outcomes are not theoretical. They occur regularly in large enterprises with ungoverned Teams deployments. And when they occur, the governance restrictions that were removed because they caused friction are immediately re-implemented under emergency conditions — which is far more disruptive than implementing them correctly from the start.

The message to leadership:

Teams governance is not about controlling how people collaborate. It is about ensuring that the collaboration platform does not become the path of least resistance for data exfiltration, compliance violation, and security compromise. Every control in this article has a specific, articulable risk it mitigates. Present governance decisions in risk terms, not in control terms, and the organisational conversation becomes fundamentally different.

---

A Practical 90-Day Teams Governance Programme

If your Teams environment currently has no formal governance, here is a realistic 90-day programme to establish the foundation:

Days 1–30 — Measure and establish baseline:

• Run Teams usage reports — count total Teams, active vs inactive, owned vs ownerless
• Export guest account list and last sign-in data
• Export third-party app installation data
• Document current Teams admin center configuration
• Identify the 10 highest-risk Teams (sensitive content, external membership, no owner)
• Present findings to IT leadership and security team

Days 31–60 — Implement foundational controls:

• Restrict Team creation to approved users/process
• Enable Group expiration policy (180 days)
• Configure guest access capabilities (scope down from defaults)
• Implement quarterly guest access review in Entra ID Identity Governance
• Block all third-party apps by default; create approved app list from existing installations
• Configure sensitivity labels for Teams (Groups and Sites scope)
• Assign missing Team owners for the 10 highest-risk Teams identified in Days 1–30

Days 61–90 — Governance operating model and communication:

• Publish Team creation request process with SLA
• Train IT team on governance tools and monthly monitoring
• Configure external access (federation) to domain allow-list
• Communicate governance changes to all Teams owners — purpose, impact, what is changing
• Define Teams governance metrics and baseline measurement
• Report initial governance metrics to leadership

At Day 90, the foundation is established. The programme is then ongoing — monthly monitoring, quarterly access reviews, quarterly lifecycle reviews, annual governance framework review.

---

Conclusion: The Platform Reflects the Governance Decisions You Made

Walk into any enterprise Teams environment today and you are looking at the accumulated result of every governance decision — and every governance non-decision — that has been made over the past four years.

The Teams with no owners. The guest users who have been gone for two years. The apps with permissions to read your messages. The meeting recordings nobody manages. The private channels nobody knows about. The federated external users from organisations whose security posture nobody reviewed. The sensitivity label that was never applied because the creation process never asked for it.

Every one of these is a governance decision that was not made deliberately — and so was made by default, in the direction of least resistance, in favour of collaboration speed over governance discipline.

The good news is that Microsoft has built comprehensive governance controls into Teams. Every control described in this article is available in the Microsoft 365 platform your organisation already licences. This is not a case of needing to buy additional technology. It is a case of using the technology you already have, deliberately, in a structured programme with defined ownership and measured outcomes.

The Teams environment you have today reflects the governance decisions of the past. The Teams environment you have in 12 months will reflect the governance decisions you make now.

Make them deliberately.

Suvankar Chakraborty is a Principal Engineer with 15+ years of experience in Identity & Access Management, Microsoft 365, Intune/Endpoint Management, and IT Operations. Connect with him on LinkedIn for more technical content on IAM, Zero Trust, and enterprise IT operations.

Read next:

• M365 Tenant Hardening — A Security Checklist for IT Managers
• SharePoint Permissions — The Audit That Will Surprise You
• Conditional Access Policies That Actually Work in Production
• RBAC vs ABAC — Which Access Model Fits Your Enterprise?