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 alert-linked scripts:

When a script is linked to an alert rule, the following happens automatically:

1. An incoming event matches the alert rule’s conditions
2. LT Auditor ^MP generates an alert
3. PowerShell Orchestrator immediately executes the linked script against the configured target
4. The script output is forwarded to LT Auditor ^MP and associated with the alert for investigation

This creates a closed-loop response — the alert fires, evidence is automatically collected, and the results are immediately available in the platform for review.

Common alert-linked script use cases:

[Your administrator should define the automated response workflows most relevant to your environment and configure them accordingly.]

Prerequisites:

Before linking a script to an alert rule, confirm the following:

• The alert rule is already created and active in LT Auditor ^MP (see Configuring Alert Rules)
• The script is already created and tested in the PowerShell Orchestrator script library (see Creating and Scheduling Scripts)
• The script’s target endpoint or cloud target is reachable and connected

Linking a script to an alert rule:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Manage
3. Select the Environment and Category containing the alert rule
4. Locate the alert rule you want to link a script to and click the Edit icon
5. In the filter configuration, navigate to the Actions tab
6. Click Add Action
7. Select Run PowerShell Script as the action type
8. Configure the action:
   • Script — select the script from your PowerShell Orchestrator library
   • Target Override (optional) — if the script should run against the machine that generated the alert rather than a fixed target, enable dynamic targeting
   • Execution Delay (optional) — set a delay in seconds before the script runs, if needed
9. Click Save Action
10. Click Save to update the alert rule

The script will now run automatically every time this alert rule fires.

Using dynamic targeting:

By default, a linked script runs against the fixed target configured in the script definition. Dynamic targeting allows the script to instead run against the machine or user that generated the alert — making the response more relevant to the specific incident.

To enable dynamic targeting:

1. In the Run PowerShell Script action configuration, enable Dynamic Target
2. Select the field from the alert event that identifies the target:
   • Host — runs the script against the machine that generated the event
   • User — passes the affected username as a parameter to the script
3. Click Save

Dynamic targeting requires that the identified machine is already a registered managed endpoint in PowerShell Orchestrator. If the machine is not registered, the script will fail to execute.

Viewing alert-linked script execution results:

When an alert fires and triggers a linked script, the execution results are available in two places:

In the alert record:

1. Navigate to Alerts → Active Alerts or Alerts → Alert History
2. Open the alert that triggered the script
3. Scroll to the Automated Response section
4. View the script execution status and output directly within the alert record

In the execution log:

1. Navigate to Configure → PowerShell Orchestrator → Execution Log
2. Filter by Trigger Type — Alert to see all alert-triggered executions
3. Click any execution entry to view full output and status details

Managing alert-linked scripts:

Removing a script link from an alert rule:

1. Open the alert rule in Manage
2. Navigate to the Actions tab
3. Locate the Run PowerShell Script action
4. Click the Delete icon next to it
5. Click Save

Temporarily suspending automated responses: If you need to stop automated script execution without modifying the alert rule itself, disable the script in the script library:

1. Navigate to Configure → PowerShell Orchestrator → Scripts
2. Open the linked script
3. Toggle the Active switch to off
4. The alert rule will continue to fire alerts, but the script will not execute until re-enabled

Best practices:

• Start with read-only assessment scripts for automated responses before implementing any scripts that make changes to your environment — collect evidence first, remediate manually until you are confident in the automation
• Always test linked scripts manually using Run Now before activating the alert rule to confirm the output is as expected
• Use dynamic targeting where possible so automated responses are relevant to the specific machine or user involved in the alert
• Monitor the execution log regularly to confirm automated responses are firing correctly and producing useful output
• Set an appropriate execution delay for scripts that need the triggering event to fully complete before the assessment runs
• Document all alert-linked scripts and their intended purpose so the team understands what automated actions may occur in response to alerts
• Review linked scripts periodically to ensure they are still appropriate as your environment evolves

[Your administrator should establish a review process for automated response workflows, particularly any scripts that make changes to directory objects or account configurations.]

Recommended starting alerts:

Creating a new alert rule:

1. In the Web UI, navigate to Manage → Add Filter
   
2. Select the target Environment and Category the rule applies to
   
3. Configure the filter details:
   
   • Filter Name — a clear, descriptive name for the alert (e.g., “Failed Logins — Threshold Exceeded”)
   • Description — the purpose and criteria of the alert
   • Priority — the order in which this rule is evaluated relative to others
   • Active Status — enable or disable the rule
4. Define the filter conditions — the criteria an event must meet to trigger the alert:
   
   • Click Add Condition
   • Select a field from the log schema (e.g., Event Type, User, Severity)
   • Choose an operator (e.g., Equals, Contains, Greater Than)
   • Enter the comparison value
   • Add multiple conditions using AND/OR logic as needed
5. Under Operations, select which event types this rule applies to using the checkbox tree
   
6. Under Actions, select Alert as the action and configure:
   
   • Email Recipients — who receives the notification
   • Alert Frequency — immediate, digest, or threshold-based
   • Severity — Critical, High, Medium, or Low
7. Click Test Filter to verify the rule matches the intended events before activating
   
8. Click Save and confirm the rule is set to Active
   

Managing existing alert rules:

• To edit a rule, select it from the filter list and click the Edit icon
• To temporarily disable a rule without deleting it, toggle the Active switch off
• To delete a rule, select it and click the Delete icon — confirm when prompted

Deleting an alert rule permanently removes it and any associated configuration. Disable the rule instead if you may need it again in the future.

Best practices:

• Use descriptive names that clearly indicate what the alert is monitoring
• Set priorities carefully — rules are evaluated in priority order
• Always test rules with sample data before activating in production
• Avoid creating too many overlapping rules, which can lead to alert fatigue
• Review and audit your active alert rules regularly to keep them relevant

1. Change the default admin password Log in to the Web UI and immediately change the default administrator password to a strong, unique password.

1. Navigate to Admin → User Management
2. Select the admin account
3. Click Change Password
4. Enter and confirm a new password
5. Click Save

2. Configure SMTP for email alerts Set up email delivery so that alerts and scheduled reports can be sent to your team.

1. Navigate to Admin → SMTP Settings
2. Enter your mail server details:
   • SMTP Host
   • Port
   • Authentication credentials
   • From address
3. Send a test email to confirm delivery
4. Click Save

[Your administrator should fill in the specific SMTP server details for your environment.]

3. Install and connect modules Install the relevant modules for your environment and confirm they are sending data to the LT Auditor ^MP server. Refer to each module’s dedicated documentation section for full instructions.

4. Configure monitored scopes Define which servers, directories, and systems LT Auditor ^MP should monitor.

1. Navigate to Configure → Environments
2. Add each environment relevant to your deployment (Windows, Linux, eDirectory, etc.)
3. Define log categories and operations to capture within each environment
4. Save your configuration

5. Set up alert rules Configure at minimum a basic set of alert rules to notify your team of critical events. See the Configuring Alert Rules article for full instructions.

Recommended starting alerts:

• Failed login threshold exceeded
• Privileged account changes
• File deletion on sensitive directories
• New admin account created

6. Configure data retention policy Set how long audit data is retained in the database to manage storage and meet compliance requirements.

1. Navigate to Admin → Retention Settings
2. Set the retention period in days
3. Click Save

7. Set up user roles and access Create user accounts and assign appropriate roles for your team before sharing access to the platform.

1. Navigate to Admin → User Management
2. Add user accounts for each team member
3. Assign roles based on responsibilities (admin, analyst, report viewer, etc.)
4. Save all changes

8. Test an alert end-to-end Before going live, confirm that the full alert pipeline is working correctly.

1. Trigger a test event that matches one of your alert rules
2. Confirm the alert appears in Alerts → Active Alerts
3. Confirm the alert notification email is received
4. Resolve the test alert