Data-35022 : On-Demand Scans Configured for Sensitive Information Discovery #760
Conversation
There was a problem hiding this comment.
Pull request overview
This PR implements a new assessment test (ID: 35022) to verify that on-demand scans are configured for discovering sensitive information in historical SharePoint, OneDrive, and Exchange content. The test helps organizations establish a compliance baseline by identifying sensitive data that predates auto-labeling policies.
Key changes:
- Added PowerShell test function to retrieve and validate on-demand sensitive information scan configurations
- Created markdown documentation with remediation guidance for configuring on-demand classification scans
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/powershell/tests/Test-Assessment.35022.ps1 | Implements the assessment logic to check for configured on-demand scans, retrieve scan details, and generate a comprehensive report with scan status, workloads, and sensitive information types covered |
| src/powershell/tests/Test-Assessment.35022.md | Provides background documentation and step-by-step remediation instructions for configuring on-demand classification scans in Microsoft Purview |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@kshitiz-prog |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| Checks if on-demand scans are configured for sensitive information discovery in | ||
| SharePoint, OneDrive, and Exchange. Implements dynamic SIT GUID -> friendly name | ||
| resolution and generates a markdown result suitable for inclusion in test reports. |
There was a problem hiding this comment.
The .DESCRIPTION states that the test "checks if on-demand scans are configured for sensitive information discovery in SharePoint, OneDrive, and Exchange", but the assessment logic only sets $passed based on ($scanCount -ge 1) without considering per-workload coverage. This creates a mismatch between the documented behavior and the implemented pass criteria; either the description should be relaxed to match the current implementation, or the logic should be updated to require scans for the stated workloads if that is the intended requirement.
| Checks if on-demand scans are configured for sensitive information discovery in | |
| SharePoint, OneDrive, and Exchange. Implements dynamic SIT GUID -> friendly name | |
| resolution and generates a markdown result suitable for inclusion in test reports. | |
| Checks if on-demand scans are configured for sensitive information discovery in the | |
| tenant. Implements dynamic SIT GUID -> friendly name resolution and generates a | |
| markdown result suitable for inclusion in test reports. |
| else { | ||
| $passed =$false | ||
| if ($passed) { | ||
| $testResultMarkdown = "✅ At least one on-demand scan is configured in the organization, enabling discovery and classification of historical sensitive information.`n`n" | ||
| } | ||
| else { | ||
| $testResultMarkdown = "❌ No on-demand scans are configured in the organization; historical sensitive data cannot be discovered.`n`n" |
There was a problem hiding this comment.
In the report-generation branch the $passed flag is unconditionally reset to $false (line 258) before the success/failure message is chosen, which means this test will always report failure even when $scanCount -ge 1 and the earlier assessment logic has already set $passed to $true. The report text and the Status value passed to Add-ZtTestResultDetail should rely on the result of the assessment logic instead of overriding it here.
| $nameEsc = $row.Name | ||
| $statusEsc = $row.Status | ||
| $workEsc = $row.Workload | ||
| $sitEsc = 'SIT Detected' |
There was a problem hiding this comment.
When building the markdown table, the SIT Detected column always outputs the literal string 'SIT Detected' (line 277) instead of the per-row sensitive information details built earlier and stored in $row.'SIT Detected'. This makes the SIT resolution and $sitString computation effectively unused in the final report; the table should use the actual value from the row object so readers can see which sensitive information types were detected.
| $sitEsc = 'SIT Detected' | |
| $sitEsc = $row.'SIT Detected' |
No description provided.