This component is particularly relevant for organizations that run mixed environments where OpenText eDirectory serves as the LDAP directory service alongside or instead of Microsoft Active Directory, and where OpenText OES servers host NSS file system volumes containing business-critical or sensitive data.

OpenText eDirectory:

OpenText eDirectory is an enterprise-grade LDAP directory service used by many organizations — particularly those with legacy NetWare infrastructure or those in education, government, and healthcare sectors — to manage user identities, authentication, and access control. eDirectory auditing captures changes and access events within the directory, including:

• User account creation, modification, and deletion
• Object creation, modification, deletion, and renaming
• Group membership and security equivalence changes
• Password changes
• LDAP authentication events
• Attribute value changes across directory objects

OpenText OES NSS (NetWare Storage Services):

OES NSS is the high-performance file system used on OpenText Open Enterprise Server (OES) Linux servers. NSS volumes are commonly used as enterprise file storage in organizations running OES infrastructure. NSS auditing captures file system activity on these volumes, including:

• File and folder reads, writes, and deletions
• File and folder creation and renaming
• Permission and trustee assignment changes
• Volume-level activity

How eDirectory & NSS Auditing works:

LT Auditor ^MP via syslog directly from the OpenText systems themselves. LT Auditor ^MP listens for incoming syslog streams on dedicated ports and processes the data through transformation rules configured in the platform.

Default port assignments:

These ports can be changed in the LT Auditor ^MP console under Configure → Transformation Rules if they conflict with other services in your environment.

Data flow:

1. eDirectory and OES NSS servers are configured to forward audit events via syslog to the LT Auditor ^MP server
2. LT Auditor ^MP receives the syslog streams on the configured ports
3. Transformation rules normalize the incoming data into structured audit records
4. Processed events are stored in the LT Auditor ^MP database and become available in the dashboard, View module, alerts, and reports

Key capabilities include:

• Real-time collection of eDirectory object and attribute change events
• Monitoring of LDAP authentication activity across eDirectory servers
• Collection of NSS file system activity from OES Linux servers
• Support for UDP, TCP, and TLS syslog transport protocols
• Configurable transformation rules for normalizing incoming log data
• Integration with LT Auditor ^MP alerting, reporting, and compliance frameworks
• Support for compliance reporting under HIPAA, GDPR, NIS2, ISO 27001, and other frameworks

Common use cases:

• Monitoring unauthorized modifications to eDirectory objects and attributes
• Tracking privileged account changes in eDirectory environments
• Auditing file access and modification on NSS volumes hosting sensitive data
• Detecting suspicious authentication patterns in eDirectory
• Producing compliance evidence for HIPAA, GDPR, and other frameworks in OpenText environments
• Bridging the gap between OpenText and Windows/cloud monitoring in mixed environments

How eDirectory & NSS Auditing fits into LT Auditor ^MP:

eDirectory & NSS Auditing extends LT Auditor ^MP ‘s coverage into OpenText infrastructure, ensuring that organizations running mixed environments have the same level of visibility across their OpenText systems as they do across Windows, Linux, and cloud environments. Events collected from eDirectory and NSS appear in the same dashboards, alert rules, and compliance reports as data from all other modules.

[Your administrator should confirm which eDirectory servers and OES NSS volumes are in scope for monitoring in your environment, and identify the appropriate person to configure the syslog forwarding settings on the OpenText systems themselves.]

Azure Log Connector replaces and significantly expands on the previous EntraConnector module. Where EntraConnector focused primarily on Entra ID identity events, Azure Log Connector extends coverage to include Microsoft 365 collaboration activity — including SharePoint Online and OneDrive — giving organizations a much more complete picture of their cloud environment.

What Azure Log Connector collects:

Azure Log Connector collects the following categories of cloud audit activity:

How Azure Log Connector works:

Azure Log Connector is installed as a Windows service on a server in your environment. It connects to Microsoft Azure and Microsoft 365 using a registered App Registration in Microsoft Entra ID, polls for new audit log entries on a configurable interval, and forwards collected events to the LT Auditor ^MP server via syslog.

Data flow:

1. Azure Log Connector authenticates to Microsoft Graph and the Office 365 Management APIs using the configured App Registration credentials
2. The collector polls for new events across all enabled log categories at the configured interval (default: every 5 minutes)
3. Collected events are forwarded to the LT Auditor ^MP server via syslog on the configured port (default: 5050)
4. Events are processed by LT Auditor ^MP transformation rules and stored in the database
5. Collected data becomes available in the LT Auditor ^MP dashboard, View module, alert rules, and compliance reports

Key capabilities include:

• Collection of sign-in, audit, and identity protection logs from Microsoft Entra ID
• Collection of SharePoint Online and OneDrive activity logs from Microsoft 365
• Configurable polling intervals and batch sizes for efficient API usage
• Lookback capability on startup to recover events missed during downtime
• Support for UDP, TCP, and TLS syslog transport to LT Auditor ^MP
• Configurable per-category enable/disable via appsettings.json
• Raw API response logging for troubleshooting purposes
• Integration with LT Auditor ^MP alerting, reporting, and compliance frameworks

Common use cases:

• Monitoring privileged role assignments and administrative changes in Entra ID
• Detecting suspicious or risky sign-in activity across your Microsoft 365 tenant
• Auditing SharePoint Online and OneDrive file access and sharing for data governance
• Tracking conditional access policy changes that may affect your security posture
• Producing compliance evidence for GDPR, HIPAA, NIS2, ISO 27001, and other frameworks
• Gaining unified visibility across both on-premises and Microsoft cloud environments

How Azure Log Connector fits into LT Auditor ^MP:

Azure Log Connector acts as the Microsoft cloud data collection layer for LT Auditor ^MP. It works alongside other modules — EventLogCentral for Windows on-premises activity, PowerShell Orchestrator for Active Directory assessments, and PII Scanner for sensitive data discovery — to give LT Auditor ^MP comprehensive coverage across your entire environment, from on-premises infrastructure to the Microsoft cloud.

Prerequisites for Azure Log Connector:

• Windows Server 2019 or newer
• Internet connectivity to Microsoft Graph and Office 365 APIs
• Administrative access to the server
• Access to the Azure Portal with permissions to create App Registrations
• LT Auditor ^MP server installed and running
• Outbound network access to the LT Auditor ^MP syslog listener port

[Your administrator should confirm which Microsoft 365 services and Azure log categories are in scope for collection in your environment, and ensure the App Registration is created by someone with the appropriate privileges in your Azure tenant.]

When to run an on-demand scan:

Prerequisites:

Before running an on-demand scan, confirm the following:

• At least one PII Scanner client agent is Online in the PII Scanner Server web UI
• The agent has read access to the path you want to scan
• At least one target host (LT Auditor ^MP) is configured in Admin → Target Hosts
• The PII detection rules relevant to your scan are enabled in Admin → PII Patterns
• No firewall is blocking communication between the agent and the PII Scanner Server or between the PII Scanner Server and LT Auditor ^MP

Running an on-demand scan:

Log in to the PII Scanner Server web UI at:

https://<PII_Scanner_Server_IP>:52766

2. Navigate to Admin → Jobs
   
3. Click Add Job
   
4. Configure the job:
   
   Job Name Use a name that clearly identifies this as an on-demand scan and captures its context:
   
   • On-Demand — HR Share Audit Prep — May 2026
   • Incident Response Scan — FileServer01 — 2026-05-15
   • New Share Baseline — Finance Q2 2026

Client Select the agent that has access to the path you want to scan. Confirm the agent shows as Online in the dropdown.

Path to Scan Enter the full path to the directory or share to scan:

Windows:

\\fileserver01\departments\hr

C:\SensitiveData

 Linux:

/mnt/shares/finance

/home/shared/legal

 Include Extensions (optional) For a focused on-demand scan, limit to the most relevant file types to reduce scan time:

*.docx, *.xlsx, *.pdf, *.txt, *.csv

5.  Leave blank to scan all file types for a comprehensive sweep.
   
   PII Classes Select the PII detection patterns relevant to this scan. For an incident response or audit scan, consider enabling all available classes for maximum coverage.
   
   Target Host Select your LT Auditor ^MP server as the destination for scan results.
   
6. Click Queue Job
   

The job is submitted immediately with a status of Queued. The assigned agent will claim it on its next poll cycle (default: every 1 minute) and begin scanning.

Monitoring the scan in progress:

1. Navigate to Admin → Jobs
2. Locate your job — the status will update from Queued to Running once the agent claims it
3. Review the job progress:
   • Started — the time the agent began scanning
   • Records Processed — the number of files scanned so far
   • Status — current state of the job
4. Refresh the page periodically to see updated progress

For large directories, scans can take a significant amount of time. The agent scans files sequentially and forwards matches to LT Auditor ^MP in real time as they are found — you do not need to wait for the scan to complete to begin reviewing results.

Viewing results as the scan runs:

Because PII matches are forwarded to LT Auditor ^MP in real time, you can begin reviewing results before the scan completes:

1. Log in to the LT Auditor ^MP Web UI in a separate browser tab
2. Navigate to View
3. Select the environment and category configured to receive PII Scanner data
4. Set the date range to Today or Last Hour
5. Filter by Source — PII Scanner
6. Results will populate as the agent finds and forwards matches
7. Click any result row to view full details:
   • File Path — where the PII was found
   • PII Class — the type of sensitive data matched
   • Line Number and Context — the location and surrounding content in the file
   • Timestamp — when the match was detected
   • Agent — which client agent performed the scan

Confirming scan completion:

1. Return to the PII Scanner Server web UI
2. Navigate to Admin → Jobs
3. Locate your scan job
4. Confirm the status has updated to Succeeded
5. Note the Completed timestamp and Records Processed count for your records

If the job status shows Failed:

1. Review the error details in the job record
   

Check the agent logs for more specific error information:

Linux:

cat /opt/bluelance/scanner/scanner.log

 Windows:

C:\Program Files\Blue Lance 2-0\LTA_PII_Scanner\logs\

3. Resolve the identified issue and requeue the job if needed
   

Documenting on-demand scan results:

For scans run in response to audits, incidents, or compliance queries, document the scan and its results:

1. Note the job name, scan path, date, time, agent, and PII classes used
2. In LT Auditor ^MP, navigate to View and filter for the scan results
3. Export the results:
   • Click Export
   • Choose PDF for audit submission or CSV for detailed analysis
   • Click Download
4. Retain the export as evidence of the data discovery activity

[Your administrator should establish a standard process for documenting and retaining on-demand scan records, particularly those run in response to security incidents or compliance audits.]

Best practices:

• Always confirm the assigned agent is online before queuing an on-demand scan — a job assigned to an offline agent will remain in Queued status until the agent comes back online
• For incident response scans, enable all PII classes for maximum coverage rather than limiting to a subset
• Use specific, descriptive job names that capture the date, scope, and reason for the scan so the jobs list serves as an auditable record
• For very large directories, consider breaking the scan into multiple smaller jobs by subdirectory — this makes progress easier to monitor and reduces the impact of a failure partway through
• Begin reviewing results in LT Auditor ^MP as the scan runs rather than waiting for completion — this is especially important during incident response when time is critical
• Export and retain scan results immediately after completion, particularly for incident response or audit-driven scans

[Your administrator should document the on-demand scan process as part of your organization’s incident response and compliance procedures so it can be followed consistently by any team member.]

Understanding scan results:

Each result record forwarded to LT Auditor ^MP represents a single PII match found in a scanned file. A single file may generate multiple result records if it contains multiple types of PII or multiple instances of the same PII type.

Each result record includes:

• File Path — the full path to the file where the match was found
• PII Class — the type of sensitive data detected (e.g., Social Security Number, Credit Card Number)
• Severity — the severity level assigned to the detected PII class (Critical, High, Medium, Low)
• Line Number — the line in the file where the match was found
• Context — a snippet of the surrounding content to help identify the match
• Timestamp — when the match was detected during the scan
• Agent — the client agent that performed the scan
• Job Name — the scan job that generated the result
• Target Host — the LT Auditor ^MP instance the result was forwarded to

Accessing scan results in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View in the main navigation menu
3. Select the view configured for PII Scanner data, or create a new one:
   • Click Create View
   • Set the Environment to your PII Scanner environment
   • Set the Category to PII Scan Results
   • Set a default date range
   • Click Save
4. The log table populates with PII match records from your scans

Filtering scan results:

Filter by scan job:

1. Click Advanced Filters
2. Add a condition:
   • Field — Job Name
   • Operator — Equals
   • Value — the name of the specific scan job
3. Click Apply Filters

Filter by PII class:

1. Click Advanced Filters
2. Add a condition:
   • Field — PII Class
   • Operator — Equals or In
   • Value — the PII class to focus on (e.g., Social Security Number)
3. Click Apply Filters

Filter by severity:

1. Click Advanced Filters
2. Add a condition:
   • Field — Severity
   • Operator — Equals
   • Value — Critical, High, Medium, or Low
3. Click Apply Filters

Filter by file path:

1. Click Advanced Filters
2. Add a condition:
   • Field — File Path
   • Operator — Starts With or Contains
   • Value — the directory path to focus on (e.g., \\fileserver01\shares\HR)
3. Click Apply Filters

Filter by agent:

1. Click Advanced Filters
2. Add a condition:
   • Field — Agent
   • Operator — Equals
   • Value — the hostname of the agent that performed the scan
3. Click Apply Filters

Interpreting scan results:

When reviewing results, focus on the following questions:

Is the sensitive data in an expected location? PII found in designated, access-controlled directories (e.g., an HR file server with appropriate permissions) is expected. PII found in unexpected locations (e.g., a public share, a developer’s home directory, or a temporary folder) requires immediate attention and remediation.

Is the PII class appropriate for the location? Credit card numbers in a Finance share may be expected. Credit card numbers in a Marketing share are not. Review whether the type of PII found makes sense for the location it was discovered in.

How severe is the finding? Prioritize Critical and High severity findings for immediate review. Medium and Low severity findings should be reviewed but may not require urgent action.

How many files are affected? A single match in one file is very different from thousands of matches across hundreds of files. Use grouping and aggregation in LT Auditor ^MP reports to understand the scale of findings across a scan.

Viewing full result details:

1. Click on any result row in the log table
2. The detail panel opens and displays:
   • File Path — full path to the affected file
   • PII Class — the type of sensitive data detected
   • Severity — the assigned severity level
   • Line Number — where in the file the match was found
   • Context — surrounding content to help identify and validate the match
   • Timestamp — when the match was detected
   • Agent — which client agent found the match
   • Job Name — which scan job generated this result
   • Raw Log — the original forwarded syslog record
3. Click Close to return to the results table

Identifying false positives:

Not every match is a genuine PII finding. Some patterns may produce false positives — matches that technically satisfy the regex pattern but do not represent real sensitive data. For example:

• A 9-digit product code that matches an SSN pattern
• A test file containing sample data used for development
• A log file containing IP addresses matched by an IP address pattern

When reviewing results, use the Context field to validate whether a match represents real sensitive data. If a pattern is consistently generating false positives from a specific file type or location:

1. Review the detection rule in Admin → PII Patterns on the PII Scanner Server
2. Consider tightening the regex pattern to reduce false positives
3. Consider excluding the relevant file extension from future scan jobs if it consistently produces noise

Acting on scan results:

When genuine PII is found in an unexpected or unauthorized location, take the following steps:

1. Document the finding:

• Export the relevant results from LT Auditor ^MP as a PDF or CSV
• Note the file path, PII class, severity, scan date, and agent

2. Assess the risk:

• Determine who has access to the location where the PII was found
• Review access logs in LT Auditor ^MP to determine whether the file has been accessed recently
• Assess whether the finding represents a compliance violation that must be reported

3. Remediate:

• Work with the file owner or relevant department to relocate, encrypt, or delete the sensitive file
• Review and update access controls on the affected location
• Confirm remediation by running a follow-up on-demand scan of the same path after the file has been addressed

4. Report:

• If the finding represents a compliance violation, follow your organization’s incident response and breach notification procedures
• Retain scan results and remediation records as evidence for compliance audits

[Your administrator should define a standard remediation workflow for PII findings and ensure all team members know how to follow it.]

Generating PII scan reports in LT Auditor ^MP:

For compliance documentation and management reporting, generate structured reports from PII scan results:

1. Navigate to Report in the LT Auditor ^MP Web UI
2. Click Create Report
3. Configure the report:
   • Environment — PII Scanner environment
   • Category — PII Scan Results
   • Date Range — the period to cover
4. Under Columns, include:
   • File Path
   • PII Class
   • Severity
   • Timestamp
   • Agent
   • Job Name
5. Under Grouping, consider grouping by:
   • PII Class — to see a breakdown of finding types
   • Severity — to prioritize remediation efforts
   • File Path — to identify the most affected locations
6. Click Save and then Generate Report
7. Download the report as PDF for audit submission or CSV for detailed analysis

Setting up alerts for critical PII findings:

Configure LT Auditor ^MP to alert your team immediately when Critical or High severity PII is detected during a scan:

1. Navigate to Manage in the LT Auditor ^MP Web UI
2. Select the PII Scanner environment and category
3. Click Add Filter
4. Configure the filter:
   • Filter Name — e.g., Critical PII Finding Alert
   • Condition — Severity Equals Critical
   • Action — Alert
   • Recipients — your security or compliance team email addresses
5. Click Save and set to Active

Repeat for High severity findings if needed.

[Your administrator should also configure an alert for PII found in specific sensitive or unexpected locations, such as public shares or temporary directories.]

Best practices:

• Review scan results promptly after each scan completes — sensitive data findings should not sit unaddressed
• Prioritize Critical and High severity findings for immediate investigation and remediation
• Use the Context field to validate matches before acting on them — not every match is a genuine PII finding
• Export and retain scan results as part of your compliance evidence library, particularly for GDPR, HIPAA, and PCI-DSS audits
• Run a follow-up on-demand scan after remediation to confirm that sensitive data has been successfully removed from the affected location
• Track remediation progress for all findings to demonstrate to auditors that your organization acts on data discovery results
• Set up alert rules for Critical severity findings so your team is notified immediately rather than discovering findings during a scheduled review

[Your administrator should establish a regular cadence for reviewing accumulated scan results in LT Auditor ^MP — not just immediately after scans, but as part of an ongoing data governance review process.]

Understanding scan targets:

A scan target in PII Scanner consists of:

• A file system path — the directory, network share, or drive to be scanned
• A client agent — the agent that will execute the scan against that path
• File type filters — optional limits on which file extensions are included in the scan
• PII classes — the sensitive data patterns to look for during the scan

Scan targets are not configured as standalone objects in the PII Scanner administrative interface — they are defined as part of each individual scan job. Planning your targets in advance makes job creation faster and more consistent.

Planning your scan targets:

Before creating scan jobs, work through the following planning steps with your administrator:

1. Identify which file systems contain sensitive data:

Common locations that typically require scanning:

2. Identify which agent has access to each path:

Each scan job is executed by a single client agent. The selected agent must have:

• Network access to the target path
• Read permissions on the target directory and all subdirectories
• Sufficient resources (CPU, memory, disk I/O) to perform the scan without impacting other workloads

3. Determine which file types to include:

Scanning all file types provides the most complete coverage but increases scan time and resource usage. Consider filtering by extension for initial scans:

4. Confirm the LT Auditor ^MP target host:

All scan results are forwarded to LT Auditor ^MP via syslog. Confirm the LT Auditor ^MP target host is configured in the PII Scanner Server before creating scan jobs. See the Managing Target Hosts section below.

Configuring target hosts in the PII Scanner Server:

Before running any scans, configure where scan results will be sent — your LT Auditor ^MP syslog receiver.

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

2. Navigate to Admin → Target Hosts
3. Click Add Target
4. Configure the target host details:
   • Name — a friendly identifier (e.g., Production LT Auditor ^MP)
   • Target Server — the hostname or IP address of your LT Auditor ^MP server
   • Port — the syslog port configured in LT Auditor ^MP (default: 514)
   • Protocol — select UDP, TCP, or TLS

Protocol options:

Additional TLS configuration (if TLS is selected):

Example production target configuration:

• Name: Production LT Auditor ^MP
• Host: ltauditor.yourcompany.com
• Port: 6514
• Protocol: TLS
• Server Name: ltauditor.yourcompany.com
• Verify Certificate: Yes

5. Click Save

Configuring PII detection patterns:

PII Scanner uses regex-based patterns to identify sensitive data. Before running scans, review the available PII classes and confirm the right ones are enabled for your environment.

1. In the PII Scanner Server web UI, navigate to Admin → PII Patterns
2. Review the available PII classes:

3. Enable or disable individual PII classes using the Enabled toggle
4. Click the Edit icon to modify an existing pattern if needed
5. To add a custom pattern for organization-specific sensitive data:
   • Click Add Pattern
   • Enter a descriptive name
   • Enter the regex pattern
   • Set the severity level
   • Click Save

[Your administrator should review the default PII patterns and add any custom patterns required for your organization’s specific data types before running the first scan.]

Managing client agents:

Before assigning agents to scan jobs, confirm all agents are online and healthy.

1. Navigate to Admin → Clients in the PII Scanner Server web UI
2. Review the client list:

3. 
   Review each agent’s details:
   
   • Name — the machine hostname
   • IP Address — the last known IP address
   • Last Seen — the timestamp of the last check-in
4. If an agent shows as offline, check:
   
   • The LTA-Scanner service is running on that machine
   • The agent’s config.json points to the correct server IP and port
   • No firewall is blocking port 52766 between the agent and the server
5. To remove a decommissioned agent, click the Delete button next to it
   
   
   A deleted agent will automatically re-register on its next poll cycle if it is still active.
   
   

Best practices:

• Start with targeted, focused scans of your highest-risk directories before expanding to broader file system coverage
• Assign scan jobs to the agent closest to the target path to minimize network traffic during scanning
• Use file extension filters for initial scans to reduce scan time and focus on the most likely file types to contain PII
• Avoid scheduling broad scans during peak business hours — large scans can generate significant disk I/O on the scanned machine
• Confirm read permissions for the agent service account on all target paths before creating scan jobs to avoid permission errors mid-scan
• Review and update PII detection patterns regularly to ensure they reflect current data types in use in your organization
• Document your planned scan target inventory so the team has a clear picture of what is and is not in scope

[Your administrator should maintain a record of all configured target hosts and PII patterns, and review them whenever compliance requirements or the monitored environment changes.]

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.]

Understanding scan jobs:

A scan job defines:

• The client agent that will execute the scan
• The file system path to scan
• The file extensions to include or exclude
• The PII classes to detect
• The target host where results are sent (your LT Auditor ^MP server)

Each scan job is executed by a single client agent. The agent claims the job on its next poll cycle, executes the scan, forwards any matches to LT Auditor ^MP in real time, and reports completion back to the PII Scanner Server.

Scan results are not stored in the PII Scanner Server. All detected PII matches are forwarded directly and exclusively to LT Auditor ^MP via the configured target host.

Accessing scan job management:

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

2. Navigate to Admin → Jobs
3. The jobs list displays all scan jobs with their name, assigned agent, target path, status, and timestamps

Creating a new scan job:

1. Click Add Job
2. Configure the job details:

Job Name (required) A descriptive identifier for the scan. Use a name that clearly communicates the scope and purpose:

• Q2 2026 HR File Server Scan
• Monthly Finance Share PII Sweep
• Weekly Legal Documents Scan

Client (required) Select the registered agent that will execute the scan from the dropdown list. The selected agent must:

• Be currently Online
• Have read access to the specified scan path
• Have sufficient resources to perform the scan

Path to Scan (required) The full path to the directory or file to scan.

Windows path examples:

C:\SharedDocuments

\\fileserver01\departments\hr

D:\Projects\Legal

Linux path examples:

/mnt/shares/documents

/home/shared/data

/opt/company/archives

Include Extensions (optional) A comma-separated list of file extensions to limit the scan to. Leave blank to scan all file types:

*.docx, *.xlsx, *.pdf

*.txt, *.csv, *.log

*.doc, *.xls, *.ppt, *.docx, *.xlsx, *.pdf

PII Classes (required) Select one or more PII detection patterns to apply during the scan. Use the dual-list selector to move classes from the Available list to the Selected list. The agent will apply all selected patterns to every file it scans.

Target Host (required) Select the LT Auditor ^MP destination where scan results will be sent. Results are forwarded in real time as matches are found.

3. Click Queue Job

The job appears in the jobs list with a status of Queued. The assigned agent will claim and begin the job on its next poll cycle (default: every 1 minute).

Scheduling recurring scan jobs:

PII Scanner executes jobs on demand when queued. To schedule recurring scans, use one of the following approaches:

Option A — Windows Task Scheduler (Windows server hosting PII Scanner):

Create a scheduled task that calls a script to queue a new scan job via the PII Scanner API at your desired interval:

1. Open Task Scheduler on the PII Scanner Server
2. Click Create Task
3. Configure the trigger:
   • Daily — for frequent sensitive path monitoring
   • Weekly — for broader file system sweeps
   • Monthly — for comprehensive archive scans
4. Configure the action to call your job queuing script
5. Save the task

[Your administrator should create and document the job queuing script and scheduled task configuration for your environment.]

Option B — Linux Cron Job (Linux server hosting PII Scanner):

Add a cron job to queue scan jobs at your desired interval:

# Open crontab editor

crontab -e

# Example: Queue a scan job every Monday at 2:00 AM

0 2 * * 1 /opt/bluelance/scanner/queue_scan_job.sh

# Example: Queue a scan job on the 1st of every month at midnight

0 0 1 * * /opt/bluelance/scanner/queue_scan_job.sh

[Your administrator should create and document the job queuing script and cron job configuration for your environment.]

Recommended scan schedule:

[Your administrator should adjust scan frequency based on your organization’s data handling practices and compliance requirements.]

Understanding the job lifecycle:

Once a job is queued, it progresses through the following statuses:

Monitoring active scan jobs:

While a scan is running, monitor its progress in the jobs list:

1. Navigate to Admin → Jobs
2. Locate the running job — it will show a status of Running
3. Review the job details:
   • Client — the agent executing the scan
   • Path — the directory being scanned
   • Started — when the agent claimed and began the job
   • Records Processed — the number of files scanned so far
4. Refresh the page periodically to see updated progress

Viewing completed scan results:

Scan results are not stored in the PII Scanner Server — all matches are forwarded to LT Auditor ^MP in real time. To view results after a scan completes:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to View
3. Select the environment and category configured to receive PII Scanner data
4. Set the date range to cover the scan period
5. Filter by Source — PII Scanner or by the job name if available
6. Review the results — each match includes:
   • The file path where PII was found
   • The PII class that matched
   • The line number and context of the match
   • The timestamp of detection

Managing scan jobs:

Cancelling a running job: If a scan job needs to be stopped before completion:

1. Locate the running job in the jobs list
2. Click the Cancel button next to it
3. Confirm the cancellation The agent will stop scanning on its next check-in cycle.

Requeuing a failed job: If a job fails and needs to be rerun:

1. Locate the failed job in the jobs list
2. Review the error details to identify and resolve the cause
3. Click Requeue to submit the job again
4. Confirm the agent is online before requeuing

Deleting a completed job:

1. Locate the job in the jobs list
2. Click the Delete icon
3. Confirm the deletion

Deleting a completed job removes it from the jobs list. Results already forwarded to LT Auditor ^MP are retained and are not affected.

Best practices:

• Schedule broad scans outside of business hours to minimize impact on file server performance and user productivity
• Break large file systems into multiple focused scan jobs rather than one enormous scan — this makes it easier to monitor progress and isolate failures
• Always confirm the assigned agent is online before queuing a job — a job assigned to an offline agent will remain in Queued status indefinitely
• Start with your highest-risk directories (HR, Finance, Legal) before expanding scan coverage to lower-risk areas
• Use descriptive job names that include the scope, date, and purpose so the jobs list remains organized and auditable
• Review scan results in LT Auditor ^MP promptly after each scan to identify and act on any sensitive data found in unexpected locations
• Retain a record of completed scan jobs and their results as evidence of your data discovery program for compliance audits

[Your administrator should document your organization’s scan schedule, the paths covered by each job, and the agents assigned to each path so the scanning program is fully auditable.]

PII Scanner helps organizations understand where sensitive data lives in their environment — a critical requirement for frameworks like GDPR, HIPAA, PCI-DSS, and NIS2, which mandate that organizations know what sensitive data they hold and who has access to it.

How PII Scanner works:

PII Scanner uses a distributed architecture consisting of two components:

PII Scanner Server A centralized web application that administrators use to create and manage scan jobs, configure PII detection patterns, manage client agents, and monitor scan progress. The server does not store scan results — all detected PII matches are forwarded directly to LT Auditor ^MP in real time.

PII Scanner Client Agents Lightweight scanning agents installed on the machines whose file systems you want to scan. Agents poll the PII Scanner Server for available jobs, claim and execute assigned scans, and send any detected PII matches to LT Auditor ^MP via syslog as matches are found.

Scan workflow:

1. Administrator creates a scan job via the PII Scanner Server web UI
2. A client agent polls the server and claims the job
3. The agent scans the specified file path using the configured PII detection patterns
4. Any matches are sent in real time to LT Auditor ^MP via syslog
5. The agent reports job completion back to the server
6. Results are available in LT Auditor ^MP for review, alerting, and reporting

Key capabilities include:

• Detection of a wide range of PII and PHI data types using regex-based pattern matching
• Support for scanning Windows and Linux file systems and network shares
• Configurable file type filtering — scan all files or limit to specific extensions
• Real-time forwarding of scan results to LT Auditor ^MP via UDP, TCP, or TLS syslog
• Centralized scan job management through a web-based administrative interface
• Support for multiple simultaneous client agents across large environments
• Scheduled and on-demand scanning

Supported PII data types include:

• Social Security Numbers (SSNs)
• Credit card numbers
• Email addresses
• Phone numbers
• Dates of birth
• Medical record numbers
• Custom regex patterns defined by your administrator

Common use cases:

• Identifying where PII and PHI data is stored across your file systems
• Detecting sensitive data in unexpected or unauthorized locations
• Supporting GDPR, HIPAA, PCI-DSS, and NIS2 compliance requirements
• Producing evidence of data discovery efforts for auditors
• Informing data classification and access control decisions

[Your administrator should confirm which PII data types and file systems are in scope for scanning in your environment, and ensure scanning activity complies with any applicable data privacy policies.]

Supported frameworks include:

• HIPAA
• NIST 171
• GDPR
• NIS2
• ISO 27001
• DORA
• FFIEC
• FDIC
• PCI-DSS

Setting up a compliance framework:

1. Navigate to Compliance in the Web UI
2. Click Add Compliance Framework
3. Configure the framework details:
   • Name — the framework name (e.g., “GDPR Compliance”)
   • Description — purpose and scope
   • Reference Code — the standard identifier (e.g., “GDPR-2016/679”)
   • Category — industry or regulation type
   • Priority — Critical, High, Medium, or Low
4. Click Save

Creating compliance rules within a framework:

Compliance rules define the specific requirements within a framework and how the system monitors them.

1. Select the compliance framework you just created
2. Click Add Rule
3. Configure the rule details:
   • Rule Name — the specific requirement (e.g., “Access Logging Required”)
   • Description — a detailed explanation of the requirement
   • Reference — the section or clause number from the framework
   • Severity — the impact level if the rule is violated
4. Link the rule to audit data:
   • Environment — which environment this applies to
   • Category — which log category to monitor
   • Operations — which specific operations must be logged
5. Define compliance criteria:
   • Must Exist — certain events must be present in the audit data
   • Must Not Exist — certain events must never occur
   • Count Thresholds — minimum or maximum event counts
   • Time Constraints — events must occur within defined timeframes
6. Click Save

Linking reports to compliance rules:

Associating reports with compliance rules automates evidence collection for audits.

1. Open the compliance rule configuration
2. Navigate to the Linked Reports tab
3. Click Link Report
4. Select the reports that provide evidence of compliance for this rule
5. Click Save

Generating compliance reports on demand:

1. Navigate to Compliance → Reports
2. Select the compliance framework
3. Choose the time period to cover
4. Select which rules to include:
   • All Rules
   • Non-Compliant Rules Only
   • Critical Rules
   • Custom Selection
5. Click Generate Report
6. Download the report in your preferred format:
   • PDF — for auditor submission
   • Excel — for detailed internal analysis
   • CSV — for data processing

Scheduling compliance reports:

1. Navigate to Compliance → Scheduled Reports
2. Click Add Schedule
3. Configure the schedule:
   • Framework — which framework to report on
   • Frequency — Weekly, Monthly, Quarterly, or Annually
   • Recipients — email addresses for report delivery
   • Format — PDF, Excel, or CSV
4. Click Save

Monitoring compliance status:

1. Navigate to the Compliance Dashboard
2. Review key metrics:
   • Overall Compliance Score — percentage of rules currently met
   • Compliant Rules — rules currently satisfied
   • Non-Compliant Rules — rules with active violations
   • Pending Rules — rules awaiting validation
3. Click into any framework to drill down into individual rule status
4. Click a specific rule to view violation details, last evaluation time, and supporting evidence

Configuring compliance alerts:

Set up notifications so your team is informed immediately when a compliance violation is detected.

1. Open a compliance rule
2. Navigate to the Alerts tab
3. Click Add Alert
4. Configure:
   • Trigger Condition — when to send the alert
   • Recipients — email addresses or user groups
   • Alert Frequency — Immediate, Daily, or Weekly
   • Escalation — who to notify if the violation is not resolved
5. Click Save

Best practices:

• Group related rules logically within each framework for easier navigation
• Always link reports to compliance rules to automate evidence collection
• Define clear, measurable criteria for each rule so compliance status is unambiguous
• Schedule reports in advance of known audit periods
• Regularly review rules to ensure they reflect current regulatory requirements
• Restrict compliance configuration access to authorized personnel only
• Document remediation actions taken when violations are detected