Make Every Symantec DLP High Speed Discovery Scan Count

• With AI expanding the volume of data organizations need to scan, unnecessary scans can quickly add up, wasting time and resources. 
• Organizations can get more from their High Speed Discovery by carefully tiering data and tightening scan scope with targeted filters and file-type restrictions with incremental scanning and smart resource allocation to help focus Detection Server capacity. 
• Together, these practices can help build a faster, more defensible discovery program. 

A single person used to spend hours producing the kind of content AI generates in seconds. One prompt can draft a contract, summarize an HR report, or even produce a policy document. 

Repositories that once grew by gigabytes per quarter are now growing by gigabytes per week. Much of that content may never even get a second glance by a human.  But from a discovery perspective, it is still there—and still part of the data estate. 

Far from a gradual growth, it's actually a very different growth curve. High Speed Discovery (HSD) changed what's possible on the infrastructure side with scans speeding up to a terabyte an hour, worker nodes that scale with demand, and cluster metrics that help pinpoint bottlenecks. 

While we’ve gotten very good at making discovery fast, throughput only solves how fast you scan, not what you scan. AI-driven growth introduces a whole new challenge.

What should you actually scan?  

Discovery used to be only a how-fast problem. AI has made it a what problem, too. That’s because a cluster that scales elastically to handle more volume can scale just as efficiently to handle more noise, like temp files, backup copies, compiled binaries, media. Now, add to that a rapidly growing share of AI-generated drafts, prompt exports, duplicate content, and hallucinated near-matches that may look relevant but contain no meaningful policy violation. Point an HSD cluster at an unfiltered, AI-swollen repository and it will dutifully inspect all of it at a terabyte an hour. That sounds impressive, until you realize worker capacity gets spent processing files that were never going to contain a real match in the first place.

That’s why a smarter approach to precision in scope—like deciding what enters the scan before the cluster ever sees it—stops AI-driven volume from overwhelming even the most well-tuned discovery programs. After all, even a  fast scan of noise is still a wasted scan. 

To get you on the right path, we’ve put together seven easy steps to tighten your scope, reduce unnecessary processing, and make sure HSD spends its capacity finding real risk instead of wading through an AI-generated flood.

1. Know your data before you configure 

Before writing a filter or scheduling a scan, take a moment to assess what actually lives in the repository. Then, map content to sensitivity tiers. This gives you a practical way to decide how often to scan, where to put your resources, and what needs to be covered for compliance. 

This tiering makes even more sense when you start thinking about worker-node capacity. You don’t want a slow-moving archive scan competing with a critical HR scan for the same resources. Configure separate scan targets for each tier, setting clusters up for success when you eventually scale. 

Account for AI-generated content 

AI has added a new wrinkle to the data map. Directories where AI tools concentrate output—like Copilot drafts, ChatGPT exports, and code assistant outputs—need their own place in your data map. These documents may carry real sensitive data, but AI hallucinations can also superficially resemble it and trigger false matches. Make sure to flag these locations for policy tuning, not just more scanning. Otherwise, you can end up spending more time reviewing AI-generated noise without getting clear visibility into actual risk. 

2. Scan selectively

Every file scanned takes compute resources, and every match takes analyst time to review. And if a file can’t contain regulated data, there’s little value in sending it through the process in the first place. Apply the "so what?" test: if a policy match there wouldn't change a security decision, exclude it.

The goal here is to spend your scanning capacity where it can tell you something useful.

3. Optimize filter use for the best results 

Once you know what you want to scan, it’s time to make your filters do some heavy lifting.

• Include filters first. Scope to directories and content areas you know matter—everything outside is implicitly excluded.
• Exclude filters for noise. Layer on top of your include scope to remove temp files, backup directories, binary artifacts, and media. Never rely on excludes alone without a positive include scope.
• File type restrictions. This is the highest-leverage configuration decision because it limits what the Detection Server downloads and inspects.

Your file-type include list is also your documented scope declaration, in other words, the evidence your scan was targeted, defensible, and intentional.

4.  Scan incrementally

Full scans on every cycle are the most expensive posture you can run—and the fastest way to make even a well-tuned HSD cluster look underprovisioned. 

Incremental scanning limits each cycle to new or changed files.  A 5 TB repository changing at 500 MB/day runs daily against 500 MB, not 5 TB—a significant difference when you’re talking about worker-node capacity. If your Scan Details report shows high detection queue backlog, check scope and incremental configuration before you scale up worker nodes. More compute pointed at unfiltered volume just processes noise faster.

5. Scan non-intrusively

A good scan should always be thorough, without causing a stir or calling attention to itself. Here are three tactics to help keep it that way. 

Follow the principle of least privilege. Scan accounts need read access to everything in scope and nothing more, a least-privilege control. Document it in your access governance record. If your workflow requires resetting last-accessed timestamps after a scan or performing remediation actions (modify/delete), grant those additional permissions on a need-to-know basis.

Schedule off-peak. Scans competing with users for platform resources cause slowdowns. Schedule high-volume scans outside business hours and monitor for access complaints in the first week a new target goes live. Should the scan start affecting user experience, move it to a quieter window by using the scan pause-resume schedule feature  before adding more worker capacity. 

Size worker-node allocation to the clock and the tier. A cluster scaled for maximum throughput is scaled for capacity, and it will hit the repository as hard as it can. Provision fewer worker nodes toward Tier 1 and Tier 2 scans during business hours, shifting full capacity to them in off-peak windows. That way daytime scanning pressure on the repository stays low, without slowing down the scan itself outside those hours. 

If administrators report elevated response times during a daytime scan, that's the signal to move it to a later window rather than run it against live traffic.

6. Handle large files and archives correctly

Large files—database exports, disk images, CAD drawings—consume Detection Server memory disproportionate to their DLP value. Set a maximum file download size (30 MB is a common starting point) before the first scan runs.

But don’t try to quietly sweep oversized files under the rug. 

Silent exclusion creates an undocumented coverage gap. "It was too large and silently skipped" is never a defensible answer to an auditor. Flag oversized files to a dedicated review queue with path, size, and timestamp recorded by ignoring files that exceed the maximum content inspection. That queue will serve as evidence of a complete, intentional scope management.

Compressed archives can expand significantly in memory, e.g. a 50 MB zip reaching 500 MB on inspection. Set the threshold at which archives join the flagging queue rather than consuming unbounded resources.

7. Know your repository's limits

Every repository has structural constraints. The trick is to find them in configuration, not mid-scan or during a production incident.

• Permission boundaries: A scan account gap is a coverage gap. Map access boundaries before attesting to completeness.
• Locked files: Files held open by active processes cannot be read, so you can either schedule scans when those holding processes are idle or exclude the files.
• Circular references: Verify loop detection is enabled and set a maximum directory depth to prevent symbolic links and junctions from triggering infinite recursion.
• Long paths: Before adding them to scope, identify any paths that exceed platform limits and could cause scan errors.

Speed and precision are not competing priorities

A fast scan only gets you so far. If your HSD environment is spending its time processing files that don’t matter, more throughput just means you get through the noise faster.

The real opportunity surfaces when we pair speed and precision, eliminating any tension between them. Carefully scoped scan targets, thoughtful tiering, and incremental scanning help put Detection Server capacity where it can actually uncover risk. You get more value out of every worker node, every scan, and documented evidence to pass on to auditors without stress or second-guessing. This is how you build and scale a discovery program that can move quickly without sacrificing your coverage or leaving you with endless questions around what was scanned, what was skipped, and why.

As AI continues to expand across every layer of business, there’s more content to contend with everyday. AI has decoupled the cost of creating content from the cost of reviewing it. Generation is cheap, but inspection isn’t. No amount of cluster scaling will change that equation on its own. Precision in what enters the scan is what makes your throughput investment worth making.

That’s the balance we aim for. A HSD program should be fast and defensible, putting resources where they matter and giving you justified confidence in what you’ve covered. 

See what your High Speed Discovery is capable of with Symantec DLP

Giving security teams the controls to build a faster, more focused discovery program, Symantec DLP helps you optimize scan scope, filter out the noise, and get more from your HSD environment. Explore the latest update or contact your in-region expert for a demo. 

Check out these other blogs on optimizing DLP Network Discover performance:

• Automating Data Discovery at Scale: A Modern SOC’s Approach to DLP
• How to Optimize DLP High Speed Discovery
• High Speed Discovery with Symantec DLP 16.1

Got questions about High Speed Discovery? We have the answers.

What is High Speed Discovery?

High Speed Discovery (HSD) is a way for organizations to scan large data repositories quickly using clustered infrastructure, worker nodes, and cluster metrics to help manage throughput and identify bottlenecks. 

Why does AI-generated content make discovery more difficult?

AI-generated content increases the amount of data organizations need to account for, including drafts, prompt exports, duplicate content, and other working files. Some of that content may even contain sensitive information, while other files can create false matches or add review burden without meaningful DLP value. 

How can I make my HSD scans more efficient?

Start by understanding what is in the repository and tiering content based on sensitivity and business importance. Then use positive include filters, exclude known sources of noise, restrict file types, and use incremental scanning for new or changed files. These practices, paired with a focused data loss prevention (DLP) solution like Symantec DLP, can help make better use of worker-node capacity and focus discovery on the data that needs it.