What are common mistakes when configuring Global Ignore Lists?

Here are the most common mistakes identified by archTIS:

1. Ignoring by "Match" instead of "Location" (and vice versa)

This is the most frequent error.

• The Mistake: Ignoring a Location (like a folder) when you only meant to ignore a single Match (like a test credit card number).
• The Risk: If you ignore a folder location because it contains one false positive, you will never see real sensitive data that might be moved into that folder later.
• The Fix: Only ignore a Location if the entire path is "known safe" (for example, a system folder or an encrypted backup). If the file is a spreadsheet that users actively edit, ignore the specific Match instead.

2. Using Local Paths for Shared Resources

• The Mistake: Adding a local drive path (e.g., C:\Users\jdoe\Documents\SafeFolder) to the Global Ignore List.
• The Risk: Because it is a Global list, every Agent in the company now looks for that exact path. While harmless on other machines, it doesn't help you if another user has the same "SafeFolder" on their D:\ drive or under a different username.
• The Fix: Use Wildcards or Environment Variables where possible (for example, *\Documents\SafeFolder\*) to ensure the ignore logic works across the entire fleet.

3. Over-reliance on Wildcards

• The Mistake: Creating overly broad wildcards like *Finance* or *.zip.
• The Risk: A wildcard like *Finance* ignores the "Finance" folder, but it also ignores a file named Finance_Department_Breach_Report.docx or a folder named Refinance_Applications. You may accidentally blind the Agent to vast amounts of relevant data.
• The Fix: Be as specific as possible.
• • Instead of *Finance*, use \\Server\Share\Department\Finance\Archive\*.

4. Forgetting the "Agent Sync" Delay

• The Mistake: Adding an item to the Global Ignore List and immediately starting a scan on an endpoint.
• The Risk: Agents download only the updated Ignore List during their "Poll" interval (typically every 30–60 minutes). If you start the scan before the Agent has checked in, it uses the old list and still reports the data you just tried to ignore.
• The Fix: After updating the Global Ignore List, wait at least one hour or manually "Restart" the Spirion Endpoint Service on the target machine to force an immediate sync.

5. Ignoring "System" Folders without Verification

• The Mistake: Assuming that folders like C:\Windows or C:\Program Files never contain sensitive data and ignoring them globally.
• The Risk: Malware or "shadow IT" users often hide sensitive data in system directories precisely because they think security tools won't look there.
• The Fix: Use the Spirion Default Exclusions (which are curated by Spirion Engineering) rather than creating your own broad system-level ignores.

6. Lack of Documentation (The "Why" Problem)

• The Mistake: Adding items to the list without a clear "Ignore Reason."
• The Risk: A year later, an auditor asks why the \\Legal\Archives folder is being ignored. If there is no reason listed, you may be forced to remove the ignore and re-scan, potentially creating a massive amount of work and re-reporting.
• The Fix: Make the "Reason" field mandatory in your internal processes. Include a ticket number (for example, "Jira-1234: Authorized Test Data") so the decision can be traced back.

7. Ignoring GUIDs that Change

• The Mistake: Ignoring an Exchange folder by its GUID right before a mailbox migration (e.g., moving from On-Premise to O365).
• The Risk: When a mailbox is migrated, the Folder GUIDs often change. Your Global Ignore List still looks for the old GUID, and the Agent starts reporting "new" results for the same folder.
• The Fix: If you are in the middle of a migration, wait until the mailboxes are in their final destination before building a permanent Global Ignore List based on GUIDs.

Summary: The most dangerous mistake is over-generalization. To keep your organization safe, keep your ignores specific, documented, and verified after the Agent has had time to sync.