Performance in scanning

Your instinct is right, define and publish the policy before you scan.

Policy only evaluates each file only against the SITs referenced in auto-labeling conditions of labels published to the scanner's service account. All regresses every file against the full SIT catalogue, so cost scales with the number of patterns rather than the number of files. That's why you got a 3-day run and a saturated server for no additional signal. All gives you more hits, not more decisions.

Your numbers show it clearly: 572,895 files with matched info types but Labeled: 0. With Enforce off that's expected, but it means you now have a 573k-row haystack with no needle definition. The 96% falling into a single label also suggests the published label already has a very broad condition, worth checking, because Policy only is only as good as the policy behind it.

Suggested order: build your CUI SITs (regex/keyword, note EDM isn't supported by the on-prem scanner), create a CUI label with those as auto-labeling conditions, publish it to the scanner account only, then set the job to Policy only / Enforce Off / Manual and test on a small repo first.

One gotcha: switching to Policy only fails with "policy doesn't include any automatic labeling condition" if no such label is published to the scanner account yet.

For the server itself: drop ReportLevel from Debug, exclude the scanner temp path from AV real-time scanning, keep SQL off the scanner box, and consider splitting that repository across multiple content scan jobs or nodes.

Also worth pulling the CSV detail reports for those 41,318 failures, that's 1.2% of files never assessed, which matters more for CUI than the extra SIT hits do.

Hi sagedogusa​,

This is expected behavior when switching from Policy Only to ALL, you're essentially classifying every file against every built-in sensitive information type, which is significantly heavier on both CPU and I/O.

A few things worth checking:

• Scan scope: 3.5M files in ~4 days is actually within normal range for an on-prem scanner, but 41K failures worth investigating, pull the scanner log and look for access denied or timeout patterns.
• Policy Only is usually the right call for CUI discovery: define your SIT-based policy targeting the CUI types you care about (ITAR, NIST 800-171 categories, etc.), then run in enforce-off mode. You get the match data without the full classification overhead.
• 98K excluded files: worth reviewing your exclusion rules to make sure you're not inadvertently skipping containers where CUI might live.

The 572K files with matched information types is your real number to work with, what types are matching? That'll tell you whether your policy is scoped correctly before you run another full scan.

Hi sagedogusa​,

We’ve seen similar behavior in large repositories. In practice, Policy Only often provides the best balance between visibility and performance. We typically reserve ALL scans for initial discovery, policy validation, or major policy changes, then use targeted scans to validate and refine classifications. I’d also be curious about the root cause of the ~41k failed files.