Set up compliance boundaries in eDiscovery (preview)
Compliance boundaries create logical boundaries within an organization that control the user content locations (such as mailboxes, OneDrive accounts, and SharePoint sites) that eDiscovery managers can search. Compliance boundaries also control who can access eDiscovery cases used to manage the legal, human resources, or other investigations within your organization.
The need for compliance boundaries is often necessary for multi-national corporations that have to respect geographical boarders and regulations and for governments, which are often divided into different agencies. In Microsoft 365, compliance boundaries help you meet these requirements when performing content searches and managing investigations with eDiscovery cases.
Tip
Get started with Microsoft Security Copilot to explore new ways to work smarter and faster using the power of AI. Learn more about Microsoft Security Copilot in Microsoft Purview.
Scenario example
We'll use the scenario example in the following illustration to explain how compliance boundaries work.
In this example, Contoso LTD is an organization that consists of two subsidiaries, Fourth Coffee and Coho Winery. The business requires that eDiscovery managers and investigators can only search the Exchange mailboxes, OneDrive accounts, and SharePoint sites in their agency. Also, eDiscovery managers and investigators can only see eDiscovery cases in their agency, and they can only access the cases that they're a member of. Additionally in this scenario, investigators can't place content locations on hold or export content from a case. Here's how compliance boundaries meet these requirements.
The search permissions filtering functionality for eDiscovery controls the content locations that eDiscovery managers and investigators can search. This control means eDiscovery managers and investigators in the Fourth Coffee agency can only search content locations in the Fourth Coffee subsidiary. The same restriction applies to the Coho Winery subsidiary.
Role groups provide the following functions for compliance boundaries:
- Control who can see the eDiscovery cases in the Microsoft Purview portal. This control means that eDiscovery managers and investigators can only see the eDiscovery cases in their agency.
- Control who can assign members to an eDiscovery case. This control means eDiscovery managers and investigators can only assign members to cases that they themselves are a member of.
- Control the eDiscovery-related tasks that members can perform by adding or removing roles that assign specific permissions.
When a search permissions filter is applied to a role group, members of the role group can perform the following search-related actions as long as the permissions to perform an action is assigned to the role group:
- Search for content
- Preview search results
- Export search results
- Purge items returned by a search
Before you set up compliance boundaries
- Users must be assigned an Exchange Online license. To verify assignments, use the Get-User cmdlet in Exchange Online PowerShell.
Setting up compliance boundaries
Here's the steps for setting up compliance boundaries:
- Step 1: Identify a user attribute to define your agencies
- Step 2: Create a role group for each agency
- Step 3: Create a search permissions filter to enforce the compliance boundary
- Step 4: Create an eDiscovery case for an intra-agency investigations
Step 1: Identify a user attribute to define your agencies
The first step is to choose an attribute to use that define your agencies. This attribute is used to create the search permissions filter that limits an eDiscovery manager to search only the content locations of users who are assigned a specific value for this attribute. For example, let's say Contoso decides to use the Department attribute. The value for this attribute for users in the Fourth Coffee subsidiary would be FourthCoffee
and the value for users in Coho Winery subsidiary would be CohoWinery
. In Step 3, you use this attribute:value
pair (for example, Department:FourthCoffee) to limit the user content locations that eDiscovery managers can search.
Here are some examples of user attributes that you can use for compliance boundaries:
- Company
- CustomAttribute1 - CustomAttribute15
- Department
- Office
- CountryOrRegion (Two-letter country code)
Step 2: Create a role group for each agency
The next step is to create the role groups in the Microsoft Purview portal that align with your agencies.
To create the role groups, go to Settings > Roles and scopes in the Microsoft Purview portal and create a role group for each team in each agency that use compliance boundaries and eDiscovery cases to manage investigations.
We recommend that the role groups created for the compliance boundary don't have any roles attached to it. This role group should only be used to assign users to the role group. Separate built-in (eDiscovery Manager) or custom role groups should be used to assign roles to members. For more information about eDiscovery-related roles, see Assign eDiscovery permissions.
Using the Contoso compliance boundaries scenario, four role groups need to be created and the appropriate members added to each one.
- Fourth Coffee eDiscovery Managers
- Fourth Coffee Investigators
- Coho Winery eDiscovery Managers
- Coho Winery Investigators
Important
If a role is added or removed from a role group that you've added as a member of a case, then the role group is automatically removed as a member of the case (or any case the role group is a member of). The reason for this is to protect your organization from inadvertently providing additional permissions to members of a case. If a role group is deleted, it is removed from all cases it was a member of. We recommend that the role groups created for compliance boundaries don't have any roles assigned to them. Use separate built-in/custom role groups to assign roles to members.
Step 3: Create a search permissions filter to enforce the compliance boundary
After you've created role groups for each agency, the next step is to create the search permissions filters that associate each role group to its specific agency and defines the compliance boundary itself. You need to create one search permissions filter for each agency. For more information about creating security permissions filters, see Configure permissions filtering for eDiscovery (preview).
Here's the syntax that's used to create a search permissions filter used for compliance boundaries for the scenario in this article.
New-ComplianceSecurityFilter -FilterName <name of filter> -Users <role groups> -Filters "Mailbox_<MailboxPropertyName> -eq '<Value> '", "SiteContent_Path -like '<SharePointURL>' -or SiteContent_Path -like '<OneDriveURL>'"
Here's a description of each parameter in the command:
FilterName
: Specifies the name of the filter. Use a name that describes or identifies the agency that the filter is used in.Users
: Specifies the users or groups who get this filter applied to the search actions they perform. For compliance boundaries, this parameter specifies the role groups (that you created in Step 2) in the agency that you're creating the filter for. This parameter is a multi-value parameter so you can include one or more role groups, separated by commas.Filters
: Specifies the search criteria for the filter. For compliance boundaries, you define the following filters. Each one applies to different content locations.Mailbox
: Specifies the mailboxes or OneDrive accounts that the role groups defined in theUsers
parameter can search. This filter allows members of the role group to search only the mailboxes or OneDrive accounts in a specific agency; for example,"Mailbox_Department -eq 'FourthCoffee'"
.SiteContent
: This filter includes two separate filters. The firstSiteContent_Path
specifies the SharePoint sites in the agency that the role groups defined in theUsers
parameter can search. For example,SiteContent_Path -like 'https://contoso.sharepoint.com/sites/FourthCoffee*'
. The secondSiteContent_Path
filter (connected to the firstSiteContent_Path
filter by theor
operator) specifies the agency's OneDrive domain (also called the MySite domain). For example,SiteContent_Path -like 'https://contoso-my.sharepoint.com/personal*'
. You can also use theSite_Path
filter in place of theSiteContent
filter. TheSite
andSiteContent
filters are interchangeable, and don't affect search permissions filters described in this article.Important
Why is the
SiteContent
filter for OneDrive included in the previous search permissions filter? Although theMailbox
filter applies to both mailboxes and OneDrive accounts, the inclusion of the SharePoint filter would exclude OneDrive accounts if you didn't also include the OneDriveSite
filter. If the search permissions filter didn't include a SharePoint filter, then you wouldn't have to include a separate OneDrive filter because the Mailbox filter would include OneDrive accounts in the scope of the compliance boundary. In other words, a search permissions filter with only theMailbox
filter would include both mailboxes and OneDrive accounts.
Here are examples of the two search permissions filters that would be created to support the Contoso compliance boundaries scenario. Both of these examples include a comma-separated filters list, in which the mailbox and site filters are included in the same search permissions filter and are separated by a comma.
Fourth Coffee
New-ComplianceSecurityFilter -FilterName "Fourth Coffee Security Filter" -Users "Fourth Coffee eDiscovery Managers", "Fourth Coffee Investigators" -Filters "Mailbox_Department -eq 'FourthCoffee'", "SiteContent_Path -like 'https://contoso.sharepoint.com/sites/FourthCoffee*' -or SiteContent_Path -like 'https://contoso-my.sharepoint.com/personal*'"
Coho Winery
New-ComplianceSecurityFilter -FilterName "Coho Winery Security Filter" -Users "Coho Winery eDiscovery Managers", "Coho Winery Investigators" -Filters "Mailbox_Department -eq 'CohoWinery'", "SiteContent_Path -like 'https://contoso.sharepoint.com/sites/CohoWinery*' -or SiteContent_Path -like 'https://contoso-my.sharepoint.com/personal*'"
Note
The syntax for the Filters
parameters in the previous examples includes a filters list. A filters list is a filter that includes a mailbox filter and a site path filter separated by a comma. In the previous example, notice that a comma separates Mailbox
and SiteContent
filters: -Filters "Mailbox_<MailboxPropertyName> -eq '<Value> '", "SiteContent_Path -like '<SharePointURL>' -or SiteContent_Path -like '<OneDriveURL>'"
. When this filter is processed during the running of an eDiscovery search, two search permissions filters are created from the filters list: one mailbox filter and one SharePoint/OneDrive filter. An alternative to using a filters list would be to create two separate search permissions filters for each agency: one search permissions filter for the mailbox attribute and one filter for the SharePoint and OneDrive site attributes. In either case, the results will be the same. Using a filters list or creating separate search permissions filters is a matter of preference.
How do the search permissions filters work in this scenario?
Here's how the search permission filters are applied for each agency in this scenario.
The
Mailbox
filter is first applied to define the content locations that eDiscovery managers can search. In this case, Coho Winery eDiscovery managers can only search the mailboxes and OneDrive accounts of users whose Department mailbox property has a value of FourthCoffee; Coho Winery eDiscovery managers can only search the mailboxes and OneDrive accounts of users whose Department mailbox property has a value of CohoWinery. TheMailbox
filter is a content location filter, because it specifies the content locations that eDiscovery managers can search. In both filters, eDiscovery managers can only search content locations with a specific mailbox property value.After the content locations that can be searched are defined, the next part of the filter defines the content that eDiscovery managers can search. The first
SiteContent
filter lets Fourth Coffee eDiscovery managers only search for documents that have a site path property that contains (or starts with)https://contoso.sharepoint.com/sites/FourthCoffee
; Coho Winery eDiscovery managers can only search documents that have a site path property that contains (or starts with)https://contoso.sharepoint.com/sites/CohoWinery
. Therefore, the twoSiteContent
filters are content filters because they define the content that can be searched for. In both filters, eDiscovery managers can only search for documents with a specific document property value. All SharePoint-related filters are content filters because searchable site properties are stamped on all documents. For more information, see Configure permissions filtering for eDiscovery.Note
Although the scenario in this article doesn't use them, you can also use mailbox content filters to specify the content that eDiscovery managers can search for. The syntax for mailbox content filters is
"MailboxContent_<property> -<comparison operator> '<value>'"
. You can create content filters based on date ranges, recipients, and domains or any searchable email property. For example, this filter would allow eDiscovery managers to only search for mail items sent or received by users in the contoso.com domain:"MailboxContent_Participants -like 'contoso.com'"
. For more information about mailbox content filters, see Configure search permissions filtering.The search permissions filter is joined to the search query by the AND Boolean operator. That means when an eDiscovery manager in one of the agencies runs an eDiscovery search, the items returned by the search must match the search query and the conditions defined in the search permissions filter.
Step 4: Create an eDiscovery case for intra-agency investigations
The final step is to create a eDiscovery case in the Microsoft Purview portal and then add the role group that you created in Step 2 as a member of the case. This results in two important characteristics of using compliance boundaries:
Only members of the role group added to the case are able to see and access the case in the Microsoft Purview portal. For example, if the Fourth Coffee Investigators role group is the only member of a case, then members of the Fourth Coffee eDiscovery Managers role group (or members of any other role group) can't see or access the case.
When a member of the role group assigned to a case runs a search associated with the case, they'll only be able to search the content locations within their agency (defined by the search permissions filter that you created in Step 3.)
To create a case and assign members:
- Go to eDiscovery in the Microsoft Purview portal and create a case.
- In the list of cases, select the name of the case you created.
- Add role groups as members to the case.
Note
When adding a role group to a case, you can only add the role groups that you are a member of.
Searching and exporting content in multi-geo environments
Search permissions filters also let you control where content is routed for export and which datacenter can be searched when searching content locations in a SharePoint Multi-Geo environment.
Export search results: You can export the search results from Exchange mailboxes, SharePoint sites, and OneDrive accounts from a specific datacenter. This means that you can specify the datacenter location that search results are exported from.
Use the Region parameter for New-ComplianceSecurityFilter or Set-ComplianceSecurityFilter cmdlets to create or change which datacenter the export is routed through.
Parameter value Datacenter location NAM North American (datacenters are in the US) EUR Europe APC Asia Pacific CAN Canada Route content searches: You can route the content searches of SharePoint sites and OneDrive accounts to a satellite datacenter. This means you can specify the datacenter location where searches are run.
Use one of the following values for the Region parameter to control the datacenter location that searches run in when searching SharePoint sites and OneDrive accounts.
Parameter value Datacenter routing locations for SharePoint NAM US EUR Europe APC Asia Pacific CAN US AUS Asia Pacific KOR The organization's default datacenter GBR Europe JPN Asia Pacific IND Asia Pacific LAM US NOR Europe BRA North American datacenters If you don't specify the Region parameter for a search permissions filter, the organization's primary SharePoint region is searched. Search results are exported to the closest datacenter.
To simplify the concept, the Region parameter controls the datacenter that is used to search for content in SharePoint and OneDrive. This doesn't apply to searching for content in Exchange because Exchange content searches aren't bound by the geographic location of datacenters. Also, the same Region parameter value may also dictate the datacenter that exports are routed through. This is often necessary to control the movement of data across geographic boarders.
Note
If you're using premium eDiscovery features, the Region parameter doesn't control the region that data is exported from. Data is exported from the organization's central location. Also, searching for content in SharePoint and OneDrive isn't bound by the geographic location of datacenters. All datacenters are searched.
Here are examples of using the Region parameter when creating search permission filters for compliance boundaries. This assumes that the Fourth Coffee subsidiary is located in North America and that Coho Winery is in Europe.
New-ComplianceSecurityFilter -FilterName "Fourth Coffee Security Filter" -Users "Fourth Coffee eDiscovery Managers", "Fourth Coffee Investigators" -Filters "Mailbox_Department -eq 'FourthCoffee'", "SiteContent_Path -like 'https://contoso.sharepoint.com/sites/FourthCoffee*' -or SiteContent_Path -like 'https://contoso-my.sharepoint.com/personal*'" -Region NAM
New-ComplianceSecurityFilter -FilterName "Coho Winery Security Filter" -Users "Coho Winery eDiscovery Managers", "Coho Winery Investigators" -Filters "Mailbox_Department -eq 'CohoWinery'", "SiteContent_Path -like 'https://contoso.sharepoint.com/sites/CohoWinery*' -or SiteContent_Path -like 'https://contoso-my.sharepoint.com/personal*'" -Region EUR
Keep the following things in mind when searching and exporting content in multi-geo environments.
The Region parameter doesn't control searches of Exchange mailboxes. All datacenters are searched when you search mailboxes. To limit the scope of which Exchange mailboxes are searched, use the Filters parameter when creating or changing a search permissions filter.
If it's necessary for an eDiscovery Manager to search across multiple SharePoint regions, you need to create a different user account for that eDiscovery manager to use in the search permissions filter to specify the region where the SharePoint sites or OneDrive accounts are located. For more information about setting this up, see the "Searching for content in a SharePoint Multi-Geo environment" section in Content Search.
When searching for content in SharePoint and OneDrive, the Region parameter directs searches to either the primary or satellite location where the eDiscovery manager conducts eDiscovery investigations. If an eDiscovery manager searches SharePoint and OneDrive sites outside of the region that's specified in the search permissions filter, no search results are returned.
When exporting search results from eDiscovery, content from all content locations (including Exchange, Skype for Business, SharePoint, OneDrive, and other services that you can search by using the Content Search tool) are uploaded to the Azure Storage location in the datacenter that's specified by the Region parameter. This helps organizations stay within compliance by not allowing content to be exported across controlled borders. If no region is specified in the search permissions filter, content is uploaded to the organization's primary datacenter.
When exporting content when premium eDiscovery features are enabled, you can't control where content is uploaded by using the Region parameter. Content is uploaded to an Azure Storage location in a datacenter in your organization's central location. For a list of geo locations based on your central location, see Microsoft 365 Multi-Geo eDiscovery configuration.
You can edit an existing search permissions filter to add or change the region by running the following command:
Set-ComplianceSecurityFilter -FilterName <Filter name> -Region <Region>
Using compliance boundaries for SharePoint hub sites
SharePoint hub sites often align with the same geographical or agency boundaries that eDiscovery compliance boundaries follow. That means you can use the site ID property of the hub site to create a compliance boundary. To do this, use the Get-SPOHubSite cmdlet in SharePoint Online PowerShell to obtain the SiteId for the hub site, and then use this value for the department ID property to create a search permissions filter.
Use the following syntax to create a search permissions filter for a SharePoint hub site:
New-ComplianceSecurityFilter -FilterName <Filter Name> -Users <User or Group> -Filters "Site_Departmentid -eq '{SiteId of hub site}'"
Here's an example of creating a search permissions filter for a hub site for the Coho Winery agency:
New-ComplianceSecurityFilter -FilterName "Coho Winery Hub Site Security Filter" -Users "Coho Winery eDiscovery Managers", "Coho Winery Investigators" -Filters "Site_Departmentid -eq '44252d09-62c4-4913-9eb0-a2a8b8d7f863'"
Compliance boundary limitations
Keep the following limitations in mind when managing eDiscovery cases and investigations that use of compliance boundaries.
When creating and running a search, you can select content locations that are outside of your agency. However, because of the search permissions filter, content from those locations isn't included in the search results.
Compliance boundaries don't apply to holds in eDiscovery cases. That means an eDiscovery manager in one agency can place a user in a different agency on hold. However, the compliance boundary will be enforced if the eDiscovery manager searches the content locations of the user who was placed on hold. That means the eDiscovery manager won't be able search the user's content locations, even though they were able to place the user on hold.
If you're assigned a search permissions filter (either a mailbox or a site filter) and you try to export unindexed items for a search that includes all SharePoint sites in your organization, you'll receive the following error message:
Unable to execute the task. Reason: The scope options UnindexedItemsOnly or BothIndexedandUnindexedItems are not allowed when the executing user has a compliance security filter applied
. If you're assigned a search permissions filter and you want to export unindexed items from SharePoint, you'll have to rerun the search and include specific SharePoint sites to search. Otherwise, you'll only be able to export indexed items from a search that includes all SharePoint sites. For more information about the options when you export search results, see Export search results.Search permissions filters aren't applied to Exchange public folders.
Supported search filters include
-and
,-or
,-like
,-not
,-eq
, and-ne
. We don't recommend using other exclusion filters (such as using-notlike)
,inotlike
, etc. in a search permissions filter) for a content-based compliance boundary. Using these exclusion filters can have unexpected results if content with recently updated attributes hasn't been indexed.Respect for compliance boundaries for OneDrive sites in searches may be impacted when:
- The sites (or associated mailboxes) are moved or rehomed
- OneDrive ownership is reassigned, or more than one owner is added
- The OneDrive site is renamed/re-issued
Moving a OneDrive site can change the ownership of the content and may include creating an arbitration mailbox. When these resources are moved, there's a chance that content search results may be available across compliance boundaries. When a OneDrive site is reassigned, renamed or assigned to more than one owner, it's possible that the content from these sites may be available across compliance boundaries.
Compliance boundaries for mailboxes may be impacted when:
- The mailbox isn't associated with a licensed user (includes disabled or deleted users)
- A mailbox isn't managed or synced from Microsoft Entra ID
Additionally, there are several types of mailboxes that may produce content during search, regardless of their compliance boundaries. These mailbox types include:
- EquipmentMailbox
- GuestMailUser
- LinkedMailbox
- RoomList
- RoomMailbox
- SchedulingMailbox
- SharedMailbox
- SystemMailbox
- TeamMailbox
To make sure that the search respects your compliance boundaries as expected, you may need to update the permissions and roles for the moved resources.
More information
- If a mailbox is delicensed or soft-deleted, the user will no longer be considered within the compliance boundary. If a hold was placed on the mailbox when it was deleted, the content preserved in the mailbox is still subject to a compliance boundary or search permissions filter.
- If compliance boundaries and search permissions filters are implemented for a user, then we recommend that you don't delete a user's mailbox and not their OneDrive account. In other words, if you delete a user's mailbox, you should also remove the user's OneDrive account since mailbox_RecipientFilter is used to enforce search permission filter for OneDrive.
- Compliance boundaries and search permissions filters depend on attributes being stamped on content in Exchange, OneDrive, and SharePoint and the subsequent indexing of this stamped content.
Frequently asked questions
Who can create and manage search permissions filters (using New-ComplianceSecurityFilter and Set-ComplianceSecurityFilter cmdlets)?
To create, view, and modify search permissions filters, you have to be a member of the Organization Management role group in the Microsoft Purview portal.
If an eDiscovery manager is assigned to more than one role group that spans multiple agencies, how do they search for content in one agency or the other?
The eDiscovery manager can add parameters to their search query that restrict the search to a specific agency. For example, if an organization has specified the CustomAttribute10 property to differentiate agencies, they can append the following to their search query to search mailboxes and OneDrive accounts in a specific agency: CustomAttribute10:<value>
.
What happens if the value of the attribute that's used as the compliance attribute in a search permissions filter is changed?
It takes up to three days for a search permissions filter to enforce the compliance boundary if the value of the attribute that's used in the filter is changed. For example, in the Contoso scenario let's say that a user in the Fourth Coffee agency is transferred to the Coho Winery agency. As a result, the value of the Department attribute on the user object is changed from FourthCoffee to CohoWinery. In this situation, Fourth Coffee eDiscovery and investors will get search results for that user for up three days after the attribute is changed. Similarly, it takes up to three days before Coho Winery eDiscovery managers and investigators get search results for the user.
Can an eDiscovery manager see content from two separate compliance boundaries?
Yes, this can be done when searching Exchange mailboxes by adding the eDiscovery manager to role groups that have visibility to both agencies. However when searching SharePoint sites and OneDrive accounts, an eDiscovery manager can search for content in different compliance boundaries only if the agencies are in the same region or geo location. Note: This limitation for sites doesn't apply when premium eDiscovery features are enabled because searching for content in SharePoint and OneDrive isn't bound by geographic location.
Do search permissions filters work for eDiscovery case holds, Microsoft 365 retention policies, or DLP?
No, not at this time.
If I specify a region to control where content is exported, but I don't have a SharePoint organization in that region, can I still search SharePoint?
If the region specified in the search permissions filter doesn't exist in your organization, the default region is searched.
What is the maximum number of search permissions filters that can be created in an organization?
There's no limit to the number of search permissions filters that can be created in an organization. However, a search query can have a maximum of 100 conditions. In this case, a condition is defined as something that's connected to the query by a Boolean operator (such as AND, OR, and NEAR). The limit of the number of conditions includes the search query itself plus all search permissions filters that are applied to the user who runs the search. Therefore, the more search permissions filters you have (especially if these filters are applied to the same user or group of users), the better the chance of exceeding the maximum number of conditions for a search.
To understand how this limit works, you need to understand that a search permissions filter is appended to the search query when a search is run. A search permissions filter is joined to the search query by the AND Boolean operator. The query logic for the search query and a single search permissions filter would look like this:
<SearchQuery> AND <PermissionsFilter>
Multiple search permissions filters are combined together by the OR Boolean operator, and then those conditions are connected to the search query by the AND operator.
The query logic for the search query and multiple search permissions filters would look like this:
<SearchQuery> AND (<PermissionsFilter1> OR <PermissionsFilter2> OR <PermissionsFilter3>...)
It's possible the search query itself may consist of multiple conditions connected by Boolean operators. Each condition in the search query would also count against the 100-condition limit.
Also, the number of search permissions filters appended to a query depends on the user who is running the search. When a specific user runs a search, the search permissions filters that are applied to the user (which is defined by the Users parameter in the filter) are appended to the query. Your organization could have hundreds of search permissions filters, but if more than 100 filters are applied to the same users, then it's likely the 100-condition limit will be exceeded when those users run searches.
There's one more thing to keep in mind about the condition limit. The number of specific SharePoint sites that are included in the search query or search permissions filters also count against this limit.
To prevent your organization from reaching the conditions limit, keep the number of search permissions filters in your organization to few as possible to meet your business requirements.