Enabling Regulatory Record Labels in MS Purview: A Step-by-Step Guide

Have you heard about Regulatory Records but can't find them in MS Purview?

By default, Regulatory Records are disabled. When creating a Retention label, you'll only see two options: a regular Retention Label and Record (including Unlocked record).

The screenshot below illustrates that Regulatory Records are not available.

 To enable Regulatory Records, using PowerShell is the only available option now.

To connect to the Compliance Center (MS Purview), you will need the ExchangeOnlineManagement Module. If you haven't installed it yet, follow these steps: 

1. Install the module:

Install -Module -Name ExchangeOnlineManagment

2. Set the execution policy

Set-ExecutionPolicy RemoteSigned

3.  Import the module and connect to the Compliance Center:

Import-Module ExchangeOnlineManagement

Connect-IPPSSession -UserPrincipalName Your_UPN

4.   After connecting, execute the following command to enable Regulatory Records:

Set-RegulatoryComplianceUI -Enabled $true

The setting will take effect instantaneously.

You can verify by running the Get-RegulatoryComplianceUI command to see that the ‘Enabled’ property is set to True.

Return to the MS Purview Compliance Center and navigate to the Records Management Portal to create a new Retention label.

You can now see that “Mark items as a regulatory record “ option is available:

Compliance Boundaries

Organizations can utilize available M365 tools to ensure information segregation for compliance with regulatory requirements. One such tool is Information Barriers, which are covered in this blog post.

Another objective not addressed by Information Barriers is ensuring that eDiscovery Managers cannot breach these barriers when conducting Content Searches within the Compliance Center.

This document also outlines Compliance Boundaries as another method for segregating information.

Compliance Boundaries is another method for segregating information.

Compliance Boundaries Overview

In the M365 Compliance Center, the eDiscovery Manager Role grants Compliance officers unrestricted access to search all locations within a tenant. Additionally, eDiscovery Managers can view all discovered files, including those in sensitive mailboxes or document libraries intended for specific audiences. This behavior is intentional and necessary for eDiscovery Content Searches, as the ability to access all information within a tenant is crucial.

To address this issue, Microsoft introduced the Compliance Boundaries concept and a set of specific features to enforce these boundaries. These features complement other organizational segmentation tools such as Information Barriers but do not serve as substitutes. Instead, they work in conjunction with them and other segmentation features.

Compliance Security Filters

Compliance Security Filters offer a mechanism for segmenting data by country, region, business/organizational unit, or department, thereby setting boundaries for eDiscovery Content Searches.

In addition to ensuring organizational compliance, judicious implementation of Compliance Security Filters can help prevent the overwhelming influx of data returned by Content Searches. This, in turn, assists eDiscovery officers by reducing the volume of data they need to review.

An easy way to conceptualize Compliance Security Filters is by likening them to the views applied to a SharePoint List. Just as a View Filter in a SharePoint List fetches only items that match specific criteria, Compliance Security Filters provide access only to a restricted view of data.

While List Views offer logical data segregation and allow for criteria modification, Compliance Security Filters enforce security criteria to control access to data.

Workloads & Locations

Compliance Security Filters can be applied to the following workloads & features:

• Exchange mailboxes, including Inactive mailboxes (special configurations apply, see below)

• SharePoint Sites

• OneDrive Sites
  

Compliance Security Filters are implemented within a single Tenant and cannot be applied across different tenants.

M365 Compliance Boundaries, on the other hand, can be implemented for geographical locations, with the barriers imposed at the datacenter boundaries.

Security Filters are created for a specific location within a specific workload. This means you need to explicitly create filters for SharePoint Sites and for the mailboxes.

Planning Compliance Boundaries

To plan Compliance Boundaries effectively, start by creating a comprehensive list of the users, departments, mailboxes, Sites, and role groups that require segregation.

Next, define the specific actions that will be restricted across these boundaries when conducting eDiscovery Searches. These actions typically include Export, Preview, Purge, Search, and All. By clearly defining these restrictions, you can ensure that sensitive data remains protected and compliant with regulatory requirements.

Scalability of Compliance Security Filters

M365 does not set an upper limit on the number of Compliance Security Filters for a tenant.

However, it's important to note that performance may degrade after configuring approximately 100 Security Filters.

This performance degradation is observed solely with the number of actual Security Filter objects created within a tenant.

Creating many compound rules within each Security Filter does not affect performance.

Under the Hood

When executing an eDiscovery Content Search, M365 combines the search query with the configured Security Filter query using the "AND" operator. This ensures that the search results adhere to both the criteria specified by the eDiscovery Manager and the restrictions imposed by the Security Filters.

Multiple Filters

M365 combines multiple Security Filters using "OR" operators.

"In a Content Search query, multiple permissions filters are combined by OR Boolean operators. So results will be returned if any of the filters are true. In a Content Search, all filters (combined by OR operators) are then combined with the search query by the AND operator."

You can create multiple filters of the same type. For example:

"Mailbox_CustomAttribute10 -eq 'FTE' -and Mailbox_MemberOfGroup -eq '$($DG.DistinguishedName)'"

Using a filters list to combine filter types:

A filters list includes a mailbox filter and a site filter separated by a comma. This is the only supported method for combining different types of filters. In the following example, notice that a comma separates the Mailbox and Site filters:

-Filters "Mailbox_CustomAttribute10 -eq 'OttawaUsers'", "Site_Path -like 'https://contoso.sharepoint.com/sites/doctors*'"

When a filter containing a filters list is processed during a content search, two search permissions filters are created: one for each filter separated by a comma. For example, in the previous example, one mailbox search permissions filter and one site search permissions filter would be created.

Each component of a filters list can contain a complex filter syntax.

For example, the mailbox and site filters can contain multiple filters separated by an -or operator:

-Filters "Mailbox_Department -eq 'CohoWinery' -or Mailbox_CustomAttribute10 -eq 'CohoUsers'", "Site_ComplianceAttribute -eq 'CohoWinery' -or Site_Path -like 'https://contoso.sharepoint.com/sites/CohoWinery*'"

Plan Security Filters to combine multiple workloads and compound criteria to enhance scalability.

Implementation

Microsoft doesn't offer UI elements for Compliance Boundaries implementation. All tasks related to Compliance Boundaries must be performed using PowerShell scripts.

Compliance Security Filters are configured using the Security & Compliance Center PowerShell module.

To connect to the Security & Compliance Center, follow these steps:

1. Set the execution policy to RemoteSigned.

2. Enter your credentials.

3. Create a new PowerShell session using the New-PSSession cmdlet.

4. Import the session using the Import-PSSession cmdlet, disabling name checking.
   

Here's an example of the PowerShell commands:

Set-ExecutionPolicy RemoteSigned $UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection Import-PSSession $Session –DisableNameChecking

Remember to terminate your session after completing your tasks:

Remove-PSSession $Session

Security Permissions

To execute the compliance security filter cmdlets, your administrator must grant you permissions in the Organization Management role group in the Security & Compliance Center.

You need to connect Windows PowerShell to both the Security & Compliance Center and your Exchange Online organization to use the compliance security filter cmdlets. This is because these cmdlets require access to mailbox properties, necessitating a connection to Exchange Online. Follow the steps outlined in the next section.

Create Compliance Security Filter cmdlet

Use the New-ComplianceSecurityFilter cmdlet to create a new Compliance Security Filter.

Syntax:

New-ComplianceSecurityFilter -Action <ComplianceSecurityFilterActionType> -FilterName <String> -Users <MultiValuedProperty> -Confirm -Description <String> -Filters <MultiValuedProperty> -Region <String> -WhatIf [<CommonParameters>]

Parameters:

• Action: Type of Search Action Value Description

• Export: The filter is applied when exporting search results or preparing them for analysis in Office 365 Advanced eDiscovery.

• Preview: The filter is applied when previewing search results.

• Purge: The filter is applied when purging search results. How the items are deleted is controlled by the PurgeType parameter value on the New-ComplianceSearchAction cmdlet. The default value is SoftDelete, meaning the purged items are recoverable by users until the deleted items retention period expires.

• Search: The filter is applied when running a search.

• All: The filter is applied to all search actions.

• Confirm: The Confirm switch specifies whether to show or hide the confirmation prompt. How this switch affects the cmdlet depends on if the cmdlet requires confirmation before proceeding.

• Description: The Description parameter specifies a description for the compliance security filter. The maximum length is 256 characters. If the value contains spaces, enclose the value in quotation marks (").

• FilterName: The FilterName parameter specifies the name for the compliance security filter. If the value contains spaces, enclose the value in quotation marks (").

• Filters: The Filters parameter specifies the search criteria for the compliance security filter. The filters are applied to the users specified by the Users parameter. You can create three different types of filters:

1. Mailbox filter: Specifies the mailboxes that can be searched by the assigned users.

2. Mailbox content filter: Specifies the mailbox content the assigned users can search for.

3. Site and site content filter: Specifies site-related properties and content-related properties.

• Region: The Region parameter specifies the satellite location for multi-geo tenants to conduct eDiscovery searches in.

• Users: The Users parameter specifies the user who gets this filter applied to their searches. Valid values include one or more users, the value "All" to assign the filter to all users, and one or more role groups. You can specify multiple values separated by commas.

Note: You can't specify distribution groups with this parameter.

Examples

Add user to Security Filter:

$filterusers = Get-ComplianceSecurityFilter -FilterName PBCFilter

$filterusers.users.add("Tatiana@cloud-confidential.com")

Set-ComplianceSecurityFilter -FilterName PBCFilter -Users $filterusers.users

Remove user from Security Filter:

$filterusers = Get-ComplianceSecurityFilter -FilterName PBCFilter

$filterusers.users.remove("Oskar@cloud-confidential.com")

Set-ComplianceSecurityFilter -FilterName PBCFilter -Users $filterusers.users

Security Filter for Custom Attribute

In this example, users TAT and OSKAR are granted access to search only the mailboxes with the value CSC for the CustomAttribute1 property.

New-ComplianceSecurityFilter -FilterName CSC -Users OSKAR,TAT -Filters "Mailbox_CustomAttribute1 -eq 'CSC'" -Action Search

Security Filter for Document Library

This filter restricts access to a President Office Site document library for all users in the eDiscovery manager Role Group:

New-ComplianceSecurityFilter -FilterName NoPODocLibView -Users "All" -Filters "Site_Site -ne 'URL GOES HERE" -Action Preview

Security Filter for SharePoint Site

This filter restricts access to a CSC Site document library for the specific user (tatiana@cloud-conf.com):

New-ComplianceSecurityFilter -FilterName CountryFilter -Users tatiana@cloud-conf.com -Filters "Site_Site -eq 'URL GOES HERE" -Action All

Exchange Mailbox with Custom Attribute

This filter restricts access of a user "Oskar DG" to a Custom Attribute that points to a specific mailbox:

New-ComplianceSecurityFilter -FilterName POMailBox -Users "Oskar DG" -Filters "Mailbox_CustomAttribute9 -eq 'CSC'" -Action All

To set a custom attribute to the mailbox, use the following:

To add a mailbox to the set that searches performed by the users identified in the filter can find, update the CustomAttribute9 property as follows:

Set-Mailbox -Identity Tatiana.Z –CustomAttribute9 'CSC'

Test filter settings to assure it’s working:

Get-Recipient -RecipientType UserMailbox -RecipientPreviewFilter {CustomAttribute9 -eq 'CSC'}

Using Security Filters with Inactive Mailboxes

You can utilize Security Filters to restrict searching inactive mailboxes. Similar to a regular mailbox, an inactive mailbox requires configuration with the recipient property used to create a filter.

To display properties of inactive mailboxes, use the following script:

Get-Mailbox -InactiveMailboxOnly

Modify Compliance Security Filter

To modify existing Compliance Security Filters, use the Set-ComplianceSecurityFilter cmdlet with the following syntax:

Set-ComplianceSecurityFilter -FilterName <String> -Action <ComplianceSecurityFilterActionType> -Confirm -Description <String> -Filters <MultiValuedProperty> -Region <String> -Users <MultiValuedProperty> -WhatIf [<CommonParameters>]

Remove Compliance Security Filter

To remove a previously configured Compliance Security Filter, utilize the Remove-ComplianceSecurityFilter cmdlet with the following syntax:

Remove-ComplianceSecurityFilter -FilterName <String> -Confirm -WhatIf [<CommonParameters>]

View Compliance Security Filters

To view configured Compliance Security Filters, use the following cmdlet: Get-ComplianceSecurityFilter

Syntax:

Get-ComplianceSecurityFilter -Action <ComplianceSecurityFilterActionType> -Confirm -FilterName <String> -User <String> -WhatIf [<CommonParameters>]

Examples

To view all configured Compliance Security Filters, run the following command:

Get-ComplianceSecurityFilter | Format-Table -Auto FilterName,Action

To view a "PBC Filter" Compliance Security Filter (previously configured), run the following command:

Get-ComplianceSecurityFilter -FilterName "PBC Filter"

Additional Usage Examples

Here are some useful examples published on the Microsoft site:

This example allows members of the OneDrive eDiscovery Managers custom role group to only search for content in OneDrive for Business locations in the organization.

New-ComplianceSecurityFilter -FilterName OneDriveOnly -Users "OneDrive eDiscovery Managers" -Filters "Site_Path -like 'https://contoso-my.sharepoint.com/personal*'" -Action Search

This example prevents members of the "OneDrive Discovery Managers" role group from performing content search actions on any mailbox in the organization.

New-ComplianceSecurityFilter -FilterName NoEXO -Users "OneDrive Discovery Managers" -Filters "Mailbox_Alias -notlike '*'" -Action All

This example prevents anyone in the organization from searching for email messages that were sent or received by janets or sarad.

New-ComplianceSecurityFilter -FilterName NoSaraJanet -Users All -Filters "MailboxContent_Participants -notlike 'janets@contoso.onmicrosoft.com' -and MailboxContent_Participants -notlike 'sarad@contoso.onmicrosoft.com'" -Action Search

This example uses a filters list to combine mailbox and site filters.

New-ComplianceSecurityFilter -FilterName "Coho Winery Security Filter" -Users "Coho Winery eDiscovery Managers", "Coho Winery Investigators" -Filters "Mailbox_Department -eq 'CohoWinery'", "Site_ComplianceAttribute -eq 'CohoWinery' -or Site_Path -like 'https://contoso.sharepoint.com/sites/CohoWinery*'" -Action ALL

Information Barriers

Information barriers in Microsoft 365 (M365) refer to a set of policies and controls designed to prevent certain groups of users within an organization from communicating or collaborating with each other. These barriers are crucial for maintaining confidentiality, preventing conflicts of interest, and ensuring compliance with regulatory requirements.

The primary purpose of information barriers is to control the flow of sensitive information within an organization, especially in scenarios where different groups of users, such as employees in different departments or subsidiaries, should not have access to each other's data.

Information Barriers Benefits

• Segregation of Duties: Enforces segregation of duties by preventing certain groups of users from accessing each other's data.

• Conflict of Interest Mitigation: Mitigates conflicts of interest by restricting access to sensitive information that could lead to unethical behavior.

• Regulatory Compliance: Helps organizations meet regulatory requirements by controlling access to sensitive data and preventing unauthorized disclosures.

• Data Leakage Prevention: Reduces the risk of data leaks and misuse by restricting communication and collaboration between specific user groups.
  

Organization Segments

The Information Barriers block communication between segments established within an organization. First, segments should be carefully planned, ensuring coverage for the entire organization without leaving anyone behind. Once segments are identified, Azure AD properties are considered next. The most intuitive approach is to use the department property for the segments. Information Barriers are successful only if organization segments are properly defined, and these segments are only as effective as the underlying Azure AD structure. Therefore, addressing any Azure AD issues or messes and validating them is essential.

Another potential issue is that some organizations' department structures may not align well with the needs of Information Barriers. For example, ensuring that communication from the Directorship & Senior Management doesn't leak to the rest of the department can be challenging. In such cases, leveraging the Azure AD Department Property may not suffice. Interestingly, if the Directorship & Senior Management end up behind an Ethical Firewall, they wouldn't be able to send communications to all staff. These and other constraints could complicate the planning and implementation of Information Barriers.

If using the Department Property for creating Segments doesn't suit your organization, you can create Segments using Groups. If none of your Azure AD Properties align with your planned Segments, you can use Azure AD Custom Attributes. In this case the custom attribute would need to be properly populated for the entire organization.

Regardless of the Azure AD Properties/Attribute you choose to leverage for segmentation, you can use only one Property for creating Segments. You cannot mix Departments and Groups when creating Segments.

Lists of attributes that you can use with information barriers

Azure AD Property Name (LDAP display name)	Exchange property name
Co	Co
Company	Company
Department	Department
ExtensionAttribute1	CustomAttribute1
ExtensionAttribute2	CustomAttribute2
ExtensionAttribute3	CustomAttribute3
ExtensionAttribute4	CustomAttribute4
ExtensionAttribute5	CustomAttribute5
ExtensionAttribute6	CustomAttribute6
ExtensionAttribute7	CustomAttribute7
ExtensionAttribute8	CustomAttribute8
ExtensionAttribute9	CustomAttribute9
ExtensionAttribute10	CustomAttribute10
ExtensionAttribute11	CustomAttribute11
ExtensionAttribute12	CustomAttribute12
ExtensionAttribute13	CustomAttribute13
ExtensionAttribute14	CustomAttribute14
ExtensionAttribute15	CustomAttribute15
MSExchExtensionCustomAttribute1	ExtensionCustomAttribute1
MSExchExtensionCustomAttribute2	ExtensionCustomAttribute2
MSExchExtensionCustomAttribute3	ExtensionCustomAttribute3
MSExchExtensionCustomAttribute4	ExtensionCustomAttribute4
MSExchExtensionCustomAttribute5	ExtensionCustomAttribute5
MailNickname	Alias
PhysicalDeliveryOfficeName	Office
PostalCode	PostalCode
ProxyAddresses	EmailAddresses
StreetAddress	StreetAddress
TargetAddress	ExternalEmailAddress
UsageLocation	UsageLocation
UserPrincipalName	UserPrincipalName
Mail	WindowsEmailAddress
Description	Description
MemberOf	MemberOfGroup

Source: Microsoft

Information Barriers Architecture

Source: Microsoft

The implementation of Information Barriers will vary across M365 workloads like Exchange Online, SharePoint Online, and MS Teams due to differences in their underlying architecture.

Exchange Online and Information Barriers

The concept of an Ethical Firewall is not new for Microsoft Exchange. In Exchange, Address Book Policies (ABPs) are used to enforce Ethical Firewalls by limiting access to the directory. However, implementing Exchange Online Information Barrier requires the removal of all ABPs.

ABP cannot be removed if there is a mailbox still associated with the ABP. If the mailbox is inactive, it would need to be made active first.

Information Barriers Implementation

At present, Information Barriers can only be implemented through the use of PowerShell scripts.

Step 1: Create Organization Segments

New-OrganizationSegment -Name "segmentname" -UserGroupFilter "attribute -eq 'attributevalue'"

Let's create four different Organizational Segments:

1. Legal Department

2. HR Department

3. Sales Department

4. Research Department

New-OrganizationSegment -Name "Legal" -UserGroupFilter "Department -eq 'Legal'"

New-OrganizationSegment -Name "HR" -UserGroupFilter "Department -eq 'HR'"

New-OrganizationSegment -Name "Sales" -UserGroupFilter "Department -eq 'Sales'"

New-OrganizationSegment -Name "Research" -UserGroupFilter "Department -eq 'Research'"

Step 2: Create Information Barrier Policies

Information Barrier Policies control how information flows between the segments by either blocking or allowing information flow.

IB Policy to Block Flow of Information: PS Command:

New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsBlocked "segmentBname" -State "state"

The best practice is to initially create IB Policies in an inactive state and then activate them only after everything is set up for the entire organization.

In this example, we create IB Policies to prevent the Sales Department from communicating with the Research Department.

New-InformationBarrierPolicy -Name "Research Block Sales" -AssignedSegment "Research" -SegmentsBlocked "Sales" -State Inactive

New-InformationBarrierPolicy -Name "Sales Block Research" -AssignedSegment "Sales" -SegmentsBlocked "Research" -State Inactive

IB Policy to Allow Flow of Information:

To allow communication to be restricted to specific segments, use the SegmentAllowed when creating the Information Barrier Policy.

New-InformationBarrierPolicy -Name "policyname" -AssignedSegment "segmentAname" -SegmentsAllowed "segmentBname","segment1name" -State "state"

New-InformationBarrierPolicy -Name "Allow HR and Legal Communications" -AssignedSegment "Legal" -SegmentsAllowed "HR" -State Inactive

If there is no policy either blocking or allowing communication between segments, then communication will be permitted.

Step 3: Activate Information Barrier Policies

When we finish creating all IB Policies, we can now activate them by using the following PS cmdlet:

Set-InformationBarrierPolicy

Set-InformationBarrierPolicy -Identity "Research Block Sales" -State Active

Set-InformationBarrierPolicy -Identity "Sales Block Research" -State Active

Set-InformationBarrierPolicy -Identity "Allow HR and Legal Communications" -State Active

Step 2: Apply Information Barrier Policies

To start applying IB Policies, use the following cmdlet:

Start-InformationBarierPoliciesApplication

Applying IB Policies may take some time. You can run the following command to check the status:

Get-InformationBarrierPoliciesApplicationStatus