How can I find out which sensitive data is exposed in my Microsoft 365 tenant?

Native M365 consoles allow point-in-time checks, but do not provide a consolidated view at tenant scale. Getting a complete picture requires a tool capable of analyzing the metadata of all files, groups, and permissions across Teams, SharePoint, and OneDrive. A tenant diagnostic can be completed in one to two weeks with no additional infrastructure and without accessing file content.

What is the difference between sensitive data under GDPR and sensitive data for a business in M365?

The GDPR definition (Article 9) is narrow: it covers only data revealing specific personal characteristics (health, ethnic origin, religious beliefs, etc.). The business definition is broader: it includes any information whose disclosure would cause harm to the organization, such as financial data, contracts, or intellectual property. In M365, both categories often coexist in the same spaces. The protection measures are not identical, but the access control logic applies to both.

Can Microsoft Copilot access my employees' sensitive data?

Copilot grants no additional rights. It only accesses data the user already has permission to view through their existing M365 permissions. If an employee has access (direct or inherited) to a sensitive document, Copilot can surface it in its responses. According to Microsoft's own documentation, "Copilot only surfaces organizational data to which individual users have at least view permissions." This is why auditing and correcting permissions before deploying Copilot is a prerequisite, not a recommendation.

How long does it take to clean up sensitive data overexposure in an M365 tenant?

Four to six weeks. The first two weeks cover the diagnostic: full tenant scan, mapping of exposed sensitive data and orphaned permissions. The following weeks focus on user-driven remediation via a self-service dashboard. Organizations using this approach eliminate on average 50% of identified risks in the first cycle.

Do employees need training to participate in sensitive data remediation?

No. Each data owner receives a targeted notification and corrects their sharing settings in one click from a personalized dashboard. No training required. IDECSI platform data shows an average of 7 remediations per user per campaign when the right tools are provided.

05 October 2026

Sensitive Data in Microsoft 365: How to Identify Risks and Regain Control

80% of data breaches in organizations stem from internal errors, not external attacks. In Microsoft 365, the root cause is almost always the same: sensitive data accessible to too many people, without anyone realizing it.

The problem is not new. What changed is Copilot. Since generative AI began indexing in real time everything a user can access, "security through obscurity" no longer exists. An HR document buried in a public Teams channel, a contract shared via an anonymous link that was never deleted: Copilot surfaces them at the first relevant query, even an innocent one.

This guide answers three concrete questions: what counts as sensitive data in M365, how to assess your real exposure, and where to start to regain control.

What Is Sensitive Data in a Microsoft 365 Environment?

The answer depends on the lens you use. In an M365 environment, two definitions coexist and must not be confused.

Legal definition (GDPR): under Article 9 of the GDPR, sensitive personal data includes information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data, health data, or data concerning a person's sex life or sexual orientation. Processing this category of data is prohibited by default, with strictly defined exceptions.

Business definition: for a CISO or IT director, sensitive data means any information whose disclosure, alteration, or loss would cause significant harm to the organization. This includes data that is not "sensitive" under the GDPR definition.

Category	Examples in M365	Applicable framework
Sensitive personal data (GDPR)	HR files, medical data, religious beliefs	GDPR, Article 9 - enhanced protection
Confidential business data	Customer contracts, strategic plans, financial data, intellectual property	Trade secret law, confidentiality agreements
Critical operational data	Passwords, system configurations, admin access credentials	Operational security

In M365, both categories often coexist in the same storage spaces. An HR SharePoint site may simultaneously contain sensitive personal data (disciplinary records) and confidential business data (salary grids). M365 data volumes grow at 30 to 40% per year on average: the exposure surface expands automatically, even without new configuration errors.

Why Does Microsoft 365 Amplify Sensitive Data Overexposure?

M365 is designed for collaboration. Teams, SharePoint, and OneDrive make it easy to share quickly, co-edit in real time, and open access to external partners. That is its strength. It is also the primary vector for sensitive data overexposure.

Three mechanisms produce this overexposure silently:

1. Access rights not revoked after an internal move. A colleague changes role or leaves the company. New rights are granted, but the old ones remain active. On an M365 tenant running for three or four years, the accumulation of these orphaned permissions creates a risk surface that nobody sees in the native admin consoles.

2. Teams channels created in Public mode by mistake. When creating a team, the Public mode is sometimes selected by default or through misunderstanding ("I need everyone to see the files"). Result: all files in that team are accessible to every person in the organization, whether they are a member or not.

3. Forgotten anonymous links. A user creates an "Anyone" link to quickly share a document with an external partner. The collaboration ends. The link stays active indefinitely. Without periodic review, these links accumulate over months and years.

The Copilot factor. Microsoft 365 Copilot does not create any new access rights. It only searches data the user already has permission to access. But its semantic indexing capability via Microsoft Graph makes visible what was previously invisible. A sensitive document in a public Teams channel that no colleague had ever searched for directly will surface instantly at the first relevant prompt. According to IDECSI data, 96% of organizations report being concerned about the relationship between Copilot and their data security. That figure reflects a real shift: deploying generative AI turns a latent governance problem into an immediate operational risk.

According to a ShareGate survey of over 850 IT and security leaders, 29% of organizations have already experienced an AI-driven data exposure incident, with HR records, contracts, and strategic plans surfaced by Copilot without anyone breaking any rules. "The permissions were already there. Copilot just followed them."

For a detailed look at how Copilot interacts with M365 permissions, see: Microsoft Copilot: the challenges for Data Security.

How to Identify Sensitive Data in Your M365 Tenant

Identification is not a single action. It follows a three-step logic.

Step 1: Map the types of data present

Before protecting, you need to know what you have. The key questions are straightforward: what types of sensitive data (HR, financial, legal, health, intellectual property) exist in the environment? Where are they stored across M365 services (OneDrive, SharePoint, Teams, Exchange)? Who is the functional data owner?

This initial mapping frequently surfaces surprises: critical data stored in collaboration spaces created without governance, sensitive files in Teams channels used for a completed project, SharePoint folders that nobody has accessed in 18 months but remain wide open.

Step 2: Analyze the actual access paths

Knowing a file is sensitive is not enough. You need to know who can access it, through which path (group inheritance, direct permission, anonymous link, team membership), and whether those access rights are still legitimate today. Native M365 admin consoles allow spot checks on individual files or sites, but cannot answer this question at scale across an entire tenant.

For the technical classification and labeling of sensitive data using Microsoft Purview MIP, see our dedicated guide: Classifying and Protecting Sensitive Data with Microsoft Purview (2026).

Step 3: Identify the priority anomalies

Once the data map and access paths are documented, three categories of anomalies require immediate attention:

Collaborative spaces in Public mode containing files labeled or identified as sensitive
Active anonymous links on documents where external sharing is no longer justified
External access (guest accounts) not revoked after a collaboration ended

In IDECSI tenant audits, these three categories account for the majority of risk findings on a standard M365 tenant.

The 4 Most Common Overexposure Scenarios

Across more than one million users analyzed by IDECSI, four configurations appear consistently.

Scenario 1: Public Teams channels with sensitive files

A Teams channel created in Public mode allows any person in the organization to access the files, even without being a member. In environments of 500 to 5,000 users, dozens of public teams containing confidential data exist at any given time, with no centralized visibility for the IT team.

Scenario 2: "Anyone" links on confidential documents

The anonymous link is the most widely used sharing tool for one-off external collaboration. It is also the riskiest: no authentication required, no access audit trail, no default expiration unless the tenant is specifically configured to enforce one. A customer contract or a restructuring plan shared this way stays accessible indefinitely.

Scenario 3: Unmanaged SharePoint permission inheritance

SharePoint allows permission inheritance to be broken at any level (site, library, folder, file) to grant individual access. Over time, this flexibility generates permission structures that become unreadable. The result: individual access rights open on libraries containing HR or financial data, granted in a specific context, never revisited since.

Scenario 4: Permission accumulation from internal role changes

A promoted or relocated employee receives new access rights suited to their new responsibilities. Their old access rights are rarely revoked systematically. Over three or four years, an employee who has changed roles twice may hold permissions on data they have no longer any legitimate reason to access.

On average, during a DETOX campaign on an M365 tenant, each user has 7 remediations to carry out. In an organization of 1,000 users, that is 7,000 risk situations, a significant portion of which involve sensitive data directly.

For risks specifically related to external sharing, see: Tips for administrators: how to manage Microsoft 365 external sharing.

Regaining Control: From Identification to Lasting Governance

Identifying risks is the first step. The next question is operational: who fixes it, how, and on what timeline?

The principle of shared responsibility

IT cannot handle thousands of access situations alone. The M365 administrator does not have the business context to know whether a given access right is still legitimate. The answer is to place remediation as close to the data as possible: the functional data owner, who knows the context, validates or revokes access from a dedicated interface, without going through the admin console.

This approach reduces the load on the IT team and improves decision quality. The user knows whether the external partner still needs access to the folder. IT cannot know this.

A three-phase process

Remediating overexposed sensitive data follows a structured campaign approach:

Diagnostic (1 to 2 weeks): full scan of the M365 tenant, identification of risk points by category, mapping of exposed sensitive data (public spaces, anonymous links, external access, orphaned permissions). The diagnostic relies only on metadata, never on file content.
User-driven remediation (2 to 3 weeks): each data owner receives a notification inviting them to review and correct their sharing settings via a personalized dashboard. Corrections are made in a single click. In parallel, IT teams can run mass remediations on the most critical configurations.
Results measurement: outcomes are tracked in real time. As a reference point, Cergy-Pontoise urban community eliminated 50% of its identified risks in the first campaign and 70% after the second.

Building lasting data hygiene

A one-time campaign is not sufficient. M365 is a dynamic environment: new files are created every day, new shares opened, new employees join and others leave. Durable governance of sensitive data requires repeated campaigns, ideally every six months, to maintain the security level achieved and embed good practices across the user base.

For a complete view of data security posture management in M365, see: Microsoft 365 Copilot: Enterprise Guide (2026).

FAQ

: Native M365 consoles allow point-in-time checks, but do not provide a consolidated view at tenant scale. Getting a complete picture requires a tool capable of analyzing the metadata of all files, groups, and permissions across Teams, SharePoint, and OneDrive. A tenant diagnostic can be completed in one to two weeks with no additional infrastructure and without accessing file content.
: The GDPR definition (Article 9) is narrow: it covers only data revealing specific personal characteristics (health, ethnic origin, religious beliefs, etc.). The business definition is broader: it includes any information whose disclosure would cause harm to the organization, such as financial data, contracts, or intellectual property. In M365, both categories often coexist in the same spaces. The protection measures are not identical, but the access control logic applies to both.
: Copilot grants no additional rights. It only accesses data the user already has permission to view through their existing M365 permissions. If an employee has access (direct or inherited) to a sensitive document, Copilot can surface it in its responses. According to Microsoft's own documentation, "Copilot only surfaces organizational data to which individual users have at least view permissions." This is why auditing and correcting permissions before deploying Copilot is a prerequisite, not a recommendation.
: Four to six weeks. The first two weeks cover the diagnostic: full tenant scan, mapping of exposed sensitive data and orphaned permissions. The following weeks focus on user-driven remediation via a self-service dashboard. Organizations using this approach eliminate on average 50% of identified risks in the first cycle.
: No. Each data owner receives a targeted notification and corrects their sharing settings in one click from a personalized dashboard. No training required. IDECSI platform data shows an average of 7 remediations per user per campaign when the right tools are provided.

A diagnostic of your M365 tenant can identify your exposed sensitive data in under two weeks :