Microsoft’s September 27, 2026 guidance puts a useful administrative pattern around Microsoft Purview Sensitive Service Domain Groups: manage the destination groups as structured configuration, and use PowerShell to make repeatable changes instead of editing a long list by hand.
These groups are part of Endpoint Data Loss Prevention (DLP). They let a rule treat different websites or network destinations differently when a user prints, copies, saves, uploads, or pastes sensitive data. The security value is real, but so is the blast radius of a bad wildcard or an unreviewed script.
Why this matters now
Most organizations start with a small list of destinations, then accumulate exceptions as teams adopt SaaS tools, AI services, file-transfer sites, and browser extensions. Manual edits eventually create three problems:
- Unclear ownership: nobody can explain why a destination was added or who approved it.
- Inconsistent enforcement: similar destinations receive different actions because each policy was edited at a different time.
- Unsafe rollout: a broad wildcard blocks a legitimate business workflow before the help desk knows what changed.
PowerShell does not make a policy safe by itself. It gives the security team a way to make the desired state reviewable, repeatable, and easier to promote through test, pilot, and production.
What the groups control
Microsoft Learn documents group-level controls for these activities:
| Activity | What to decide | Evidence to retain |
|---|---|---|
| Print, copy, or save a website locally | Whether the action is audited, blocked with an override, or blocked for protected content. | The group, policy rule, user/device scope, and a test event. |
| Upload or drag a sensitive file to a destination | Which destinations are approved, monitored, or prohibited for sensitive files. | The domain match, sensitive information type or label, browser, and policy result. |
| Paste sensitive data into a browser | Whether the destination gets an audit, warning, or hard block, and whether a user justification is allowed. | The paste event, matched group, policy tip, and approved exception if one exists. |
Coverage depends on the browser and platform. Microsoft lists the broadest set of controls for Microsoft Edge. Chrome and Firefox require the Microsoft Purview browser extension for the documented paste and upload scenarios, so include the extension deployment and health check in the same control.
Design a group model before writing a script
Use names that describe the business decision, not the person who happened to create the group. A small tenant might begin with four groups:
| Group pattern | Example purpose | Default posture |
|---|---|---|
| Approved business services | Destinations that have a documented contract, owner, and data-processing decision. | Audit first; use a narrow exception only after the baseline is understood. |
| Restricted consumer and AI services | Destinations where sensitive uploads or paste actions require a hard boundary. | Block or block with override, depending on the data class and business case. |
| Regulated or high-impact destinations | Financial, healthcare, legal, or customer portals that need stricter handling. | Separate group and explicit owner; avoid inheriting a broad consumer rule. |
| Pilot and exception ring | Short-lived testing or a time-bound business exception. | Audit with an expiry date and a named approver. |
Microsoft’s built-in Generative AI Websites group is maintained by Microsoft and cannot be edited or deleted. Use it where its scope matches your policy, and create a separate organization-owned group for destinations that need a different action.
Get the matching rules right
Microsoft supports URL, IP address, and IP address range match types for Sensitive Service Domain Groups. IP matching is documented as preview functionality, and Microsoft calls out Windows-only limits for some IP-based upload actions.
- Enter host names, not a full URL: omit
https://, paths, and the trailing dot. - Use
contoso.comfor that domain and its paths; use*.contoso.comwhen subdomains are intentionally in scope. - Do not use a wildcard to compensate for an unknown inventory. A broad match is a policy decision that needs an owner and a test case.
- Keep a record of whether an entry is a URL, IP address, or IP range so a future administrator does not silently change its meaning.
Microsoft Learn documents a maximum of 100 websites in one group and 150 groups, for up to 15,000 websites assigned through group-level actions. The separate global Service domains list has its own limit of 50 domains and should not be treated as a substitute for a well-designed group model.
Use PowerShell as a controlled promotion path
Microsoft’s new post is a cmdlet-level walkthrough; use it as the canonical syntax reference for your tenant and module version. The operating model around those commands should look like this:
- Read: export the current groups, match types, destinations, and policy assignments to a versioned file. Include the tenant, operator, timestamp, and module version.
- Normalize: sort entries, standardize host-name formatting, and flag duplicates or overlapping wildcards. Do not normalize away an intentional exception without an owner’s approval.
- Review: produce a human-readable diff. A reviewer should be able to answer what will be added, removed, broadened, or moved between groups.
- Stage: apply the change in a test tenant or a tightly scoped pilot. Keep the action at audit or block-with-override while you validate real workflows.
- Verify: generate test events for upload, paste, copy, print, and save where those actions are in scope. Confirm the event names, matched group, policy result, and user experience.
- Promote: move the reviewed configuration to production, record the change reference, and set a review date. If the script fails halfway through, stop and reconcile the tenant before trying again.
Keep the actual script in source control or your approved automation repository. The valuable artifact is not only the command; it is the input file, diff, approval, output, and post-change evidence that show why the change was safe.
Pair the domain groups with DLP policy scope
A group is not an enforcement control until a DLP rule references it. For Endpoint DLP, Microsoft’s documented workflow scopes the policy to Devices, adds the relevant sensitive information types or labels, and selects the browser or service-domain activity. The action can then be set to audit, block with override, or block, with different restrictions for selected groups.
Start with one business scenario. For example, audit uploads of a customer-data label to a small set of consumer AI destinations for two weeks. Review the activity, correct false positives, and only then decide whether the control belongs in block or block-with-override. This is more defensible than switching every destination to block because a group was easy to create.
| Control layer | Question to answer | Owner |
|---|---|---|
| Destination group | Which hosts or IP ranges are in scope, and why? | Security engineering or data governance |
| DLP condition | What sensitive data or label must be present before the action applies? | Compliance or information protection |
| Action | Should the user be audited, warned, or blocked? | Risk owner with security approval |
| Device and browser readiness | Are devices onboarded and are required browser extensions healthy? | Endpoint and service desk teams |
A 30-day readiness plan
| Window | Work | Exit evidence |
|---|---|---|
| Days 1–5 | Inventory existing groups, global service domains, DLP rules, browser extensions, owners, and exceptions. | Signed inventory with scope, purpose, and current action. |
| Days 6–12 | Design the group taxonomy, remove duplicate entries, and identify broad wildcards or unmanaged destinations. | Approved target-state matrix and exception list. |
| Days 13–20 | Run the Microsoft PowerShell workflow in a test tenant or pilot ring. Exercise each protected activity that matters to the business. | Diff, test events, browser coverage, user feedback, and rollback steps. |
| Days 21–30 | Promote the reviewed configuration, brief the help desk, and schedule a 30-day effectiveness review. | Production change record, monitoring query, exception expiry dates, and owner sign-off. |
Frequently asked questions
Does this replace the DLP detection-assurance workflow? No. Detection assurance measures whether DLP controls are producing useful, explainable outcomes. Sensitive Service Domain Groups define where endpoint browser and destination controls apply. They belong in the same operating model, but they solve different problems.
Can I use one group for every AI site? Microsoft maintains a built-in Generative AI Websites group. Use it when the Microsoft-managed scope and action fit your policy; otherwise, create an organization-owned group with a narrower purpose and an explicit review owner.
Will a group block every browser? No. Behavior depends on the action, platform, browser, and required Microsoft Purview extension. Validate the exact browser paths used by your workforce before claiming coverage.
What should happen when a business owner needs an exception? Add the destination to a separately governed exception group or rule, make the approval time-bound, and record the data class, owner, compensating control, and expiry date. Do not quietly broaden a production wildcard.
Need a Purview DLP control review?
Accred Consulting can map sensitive destinations to business risk, structure Endpoint DLP groups, and build an audit-to-enforcement rollout that your security and help-desk teams can operate.
Plan a Purview DLP Review