Microsoft plans to give compliance teams direct SQL-table access to Purview Information Protection scanner data, bypassing the current scramble of local CSV exports. According to a Microsoft 365 Roadmap entry updated July 13, 2026 (ID 494839), labeling, classification, and protection actions from on-premises scanner runs will soon land in structured SQL tables, unlocking custom reporting, long-term trend analysis, and integration with existing data platforms.
Organizations that rely on the scanner to discover sensitive data across file shares and SharePoint Server libraries will be able to build recurring dashboards in Power BI or SQL Server Reporting Services without manually scraping per-machine reports. Microsoft targets a preview release in May 2026 and general availability in September 2026, though the feature remains flagged In development and those dates are not final.

The announcement: from flat files to SQL tables

Today, when the Purview Information Protection scanner crawls on-premises SMB shares, NFS mounts, or SharePoint Server libraries, it dumps two sets of output into a local reports directory: a text summary and a detailed CSV file per scan. Each scanner host holds its own siloed pile of records. Extracting company-wide insights means collecting, combining, and parsing those files—a manual chore that breaks down at scale.

The roadmap entry changes that equation. Microsoft intends to retain scanner action data directly in SQL Server tables. The exact schema hasn’t been published, but the listing explicitly mentions the ability to “assess the state of scanned repositories and build custom reports from labeling, classification, and protection activity.” That implies at least three data signals will be captured: sensitive information types discovered, labels applied or recommended, and protection actions (such as encryption or rights management) triggered by policy.

This isn’t a pivot to a new architecture. The scanner already requires a SQL Server instance for its configuration database. The forthcoming capability extends that SQL footprint to include operational outcomes—making the database a reporting source rather than just a settings store.

What this changes for compliance teams

Structured, queryable scanner data opens a door that the existing CSV-and-portal approach kept closed. Instead of spot-checking the built-in Purview portal views or building fragile spreadsheet pipelines, teams can:

  • Monitor scan coverage and label adoption over time with SQL queries or dashboard tools.
  • Identify repositories where sensitive data keeps appearing despite labeling policies.
  • Compare “discovery only” scan results against enforcement-mode runs to measure policy effectiveness.
  • Feed scanner activity into broader data-loss-prevention, audit, or governance workflows that already consume SQL data.

For organizations running hundreds of scanners across global data estates, the shift is from tactical log review to strategic oversight. A compliance officer could, for instance, pull a report that shows all files containing credit card numbers across all European file servers in the last 90 days—without logging into each scanner host.

Split-screen: home users vs. enterprise admins

  • Home users and small offices are not the target. The Purview Information Protection scanner is a Windows Server workload, tied to Microsoft 365 E5, Microsoft 365 E5 Compliance, or equivalent licensing. It requires infrastructure and administrative know-how.
  • Enterprise administrators stand to gain the most. They already manage scanner clusters, configure content scan jobs, and produce compliance reports. SQL table integration removes a brittle, manual step from their reporting workflow and gives them a single source of truth for scanner activity.
  • Developers and analytics specialists inside those enterprises can now treat scanner data like any other structured dataset—joining it with file metadata, Active Directory security group info, or incident tickets—without relying on periodic CSV dumps or the Purview portal’s limited export options.

How we arrived at SQL-backed reporting

The current scanner reporting model reflects a feature that grew incrementally. When the scanner debuted around 2020, the immediate need was to get sensitivity labels onto on-premises files. The focus was on labeling accuracy, speed, and coverage. Reporting was secondary; a local CSV and a portal summary were “good enough” to prove the scanner ran and to triage mislabeled files.

Over time, two pressures built. First, regulations like the SEC’s cyber disclosure rules and the EU’s Digital Operational Resilience Act pushed compliance monitoring from annual checks toward continuous oversight. Second, the volume of unstructured data kept growing, making it harder to answer the question “What sensitive data do we have, and is it protected?” using a point-in-time scan log.

Microsoft’s broader Purview data governance strategy also moved in this direction. The June 2025 data-governance roadmap (published in a now-archived PDF) emphasized “analytics-ready” data estates, where classification and protection signals flow into fabric-style analytics. The upcoming SQL reporting feature for the scanner fits that pattern—turning a device-level log into an enterprise data asset.

What to do right now

Until the preview arrives, no immediate action is required. However, admins who rely on the scanner should take three steps to prepare:

  1. Validate your scanner SQL instance. The scanner configuration database already runs on SQL Server. Ensure that instance has enough capacity for a second, write-heavy workload. Microsoft hasn’t disclosed whether scanner results will use the same database or a separate one, but a dedicated SQL Server or at least adequate storage and tempdb space is wise.
  2. Document your current reporting pain points. Which questions do you answer with CSV exports today? Where do manual steps break? Having that list ready will let you test the preview against real needs and provide feedback to Microsoft through the preview program.
  3. Review scanner version and deployment health. The SQL output will almost certainly require a scanner update. Make sure your scanners are on a supported Windows Server version (2022 or later is recommended) and that your Purview client has stayed current through the Microsoft 365 admin center.

Do not discard existing CSV collection and retention processes prematurely. Microsoft hasn’t committed to full feature parity; early previews may lack certain fields or show only a subset of scanner runs. Keep your existing reporting running in parallel until you’ve validated the SQL tables in production.

Outlook: the missing technical details

Several open questions will determine how quickly organizations adopt this capability:

  • Schema design. Will the tables mirror the CSV columns exactly, or will they follow a more normalized, event-driven model? A well-structured schema could make cross-repo joins effortless; a flat schema might require pre-aggregation.
  • Retention policies. Local CSV files pile up indefinitely unless manually pruned. SQL tables need explicit retention management. If Microsoft doesn’t provide purge mechanisms or retention defaults, admins will have to design their own.
  • Permissions and access control. The scanner configuration database is typically locked down. Reporting tables might need to be readable by analytics service accounts, Power BI gateways, or even auditor roles. Clarifying what permissions are required—and how they interact with Purview admin roles—will be critical.
  • Performance at scale. A scanner can touch millions of files per run. Inserting a row per file into SQL tables will generate significant I/O. Microsoft will need to document how to tune the scanner and SQL Server to avoid bottlenecks.
  • Preview program enrollment. The roadmap suggests commercial, GCC, and GCC High availability. How organizations sign up for the preview hasn’t been announced. Monitoring the Microsoft 365 admin center’s message center and the Purview tech community blog is the best way to catch enrollment instructions.

Despite the unknowns, the direction is clear. Microsoft is shifting Purview scanner reporting from a machine-bound log to a query-ready data service. Once live, it will let compliance teams ask questions about their entire data estate without moving files or running ad hoc scripts. The move also aligns with a larger industry trend: treating data security posture as a continuous, measurable process rather than a periodic check-the-box exercise.

For admins, the September 2026 GA target means there’s time to plan. Watch for the preview announcement, map out how SQL-backed reporting would fit into your compliance toolchain, and be ready to test early. When the tables land, the days of hunting for CSV files across scanner hosts may finally end.