Understanding PII detection rules:

PII Scanner ships with a set of built-in detection rules covering the most common categories of sensitive data. These built-in rules can be enabled, disabled, or modified to suit your environment. Custom rules can also be added to detect organization-specific sensitive data types that are not covered by the defaults.

Each detection rule consists of:

• Name — a descriptive label for the PII class (e.g., Social Security Number)
• Regex Pattern — the regular expression used to identify matches in file content
• Enabled Status — whether the rule is active and applied during scans
• Severity Level — the importance of a match (Critical, High, Medium, Low)

Accessing PII detection rules:

Log in to the PII Scanner Server web UI at:
https://<PII_Scanner_Server_IP>:52766

2. Navigate to Admin → PII Patterns
3. The patterns list displays all configured detection rules with their name, pattern, enabled status, and severity level

Built-in PII detection rules:

PII Scanner includes the following default detection rules:

[Your administrator should confirm which built-in rules are appropriate for your environment and compliance requirements, and disable any that generate excessive false positives.]

Enabling and disabling detection rules:

To enable or disable a built-in rule without deleting it:

1. Navigate to Admin → PII Patterns
2. Locate the rule in the patterns list
3. Click the Enabled toggle to turn the rule on or off
4. The change takes effect on the next scan job that runs

Disabled rules are not applied during scans but are retained in the system and can be re-enabled at any time. Prefer disabling over deleting built-in rules so they can be recovered if needed.

Editing an existing detection rule:

To modify the regex pattern or severity level of an existing rule:

1. Navigate to Admin → PII Patterns
2. Click the Edit icon next to the rule
3. Modify the relevant fields:
   • Name — update if needed for clarity
   • Regex Pattern — update the pattern to improve accuracy or reduce false positives
   • Severity Level — adjust based on the sensitivity of the data type
4. Click Save

Test any modified regex patterns against sample data before activating them in a scan to confirm they match the intended data and do not produce excessive false positives.

Creating a custom detection rule:

Custom rules allow you to detect organization-specific sensitive data types not covered by the built-in patterns — such as employee ID numbers, internal account codes, or proprietary data formats.

1. Navigate to Admin → PII Patterns
2. Click Add Pattern
3. Configure the custom rule:
   • Name — a clear, descriptive name for the data type (e.g., Employee ID Number)
   • Description — a brief explanation of what this pattern detects
   • Regex Pattern — the regular expression to match the data type
   • Severity Level — Critical, High, Medium, or Low based on data sensitivity
4. Click Save

Example custom patterns:

[Your administrator should work with your legal and compliance teams to identify any organization-specific data types that require custom detection rules.]

Writing effective regex patterns:

When creating or modifying detection rules, keep the following in mind:

Be specific enough to avoid false positives: A pattern that is too broad will match unintended content and generate noise in your scan results. For example, a simple \d{9} pattern would match any 9-digit number, not just Social Security Numbers.

Be flexible enough to catch real matches: Data is not always formatted consistently. SSNs may appear with or without dashes. Phone numbers may use spaces, dots, or dashes as separators. Build flexibility into patterns where appropriate:

# SSN — matches with or without dashes

\b\d{3}[-\s]?\d{2}[-\s]?\d{4}\b

# Phone — matches multiple separator styles

\b(\+1[-\s]?)?\(?\d{3}\)?[-\s.]?\d{3}[-\s.]?\d{4}\b

Use word boundaries: Add \b (word boundary) anchors to prevent partial matches within longer strings:

# Without boundary — matches “123456789” inside “9123456789”

\d{9}

# With boundary — only matches standalone 9-digit numbers

\b\d{9}\b

Test patterns before activating: Use an online regex tester with representative sample data from your environment to validate patterns before adding them to PII Scanner.

[Your administrator should involve your security or data governance team when writing custom regex patterns to ensure accuracy and compliance alignment.]

Managing detection rule severity levels:

Severity levels help prioritize scan results in LT Auditor ^MP and can be used to drive alert rules and compliance reporting. Assign severity levels based on the regulatory and business impact of each data type:

[Your administrator should define severity levels in alignment with your organization’s data classification policy.]

Reviewing detection rule effectiveness:

After running scan jobs, review the results in LT Auditor ^MP to assess whether your detection rules are performing as expected:

1. Navigate to View in the LT Auditor ^MP Web UI
2. Filter by Source — PII Scanner
3. Review the PII classes detected across recent scans
4. Identify:
   • High false positive rates — rules generating many matches that are not actually sensitive data — consider tightening the regex pattern or disabling the rule
   • Missed detections — known sensitive data that is not being detected — review and update the relevant regex pattern
   • Unexpected findings — sensitive data found in unexpected locations — flag for remediation and access control review

Best practices:

• Review and validate all built-in detection rules before running your first scan to confirm they are appropriate for your environment
• Disable built-in rules that consistently generate false positives in your environment rather than tolerating the noise
• Test all custom regex patterns thoroughly with real sample data before activating them
• Assign severity levels consistently across all rules to ensure reliable prioritization in LT Auditor ^MP
• Review detection rules regularly — data types and formats used in your organization may change over time
• Document the purpose and expected output of each custom rule so other administrators can maintain them
• Involve your legal and compliance teams when defining rules for regulated data types to ensure alignment with your compliance obligations

[Your administrator should schedule a periodic review of all active detection rules — at minimum annually, or whenever compliance requirements or data handling practices change in your organization.]