Let’s start by looking at the problem that adaptive policy scopes address. A fundamental component of policies, like data loss prevention policies, is defining their scope, as in who, where, and what will be subject to the policy. The nature or target of the policy goes a long way to determining its scope. For example, company tax records or HR payroll are by nature going to have a different scope from, say, documents related to sales pipelines. 

The first two types of data are much more limited in their audience/location and where they are created. It would be a fair assumption that in the case of tax records and payroll, the audience will be restricted to a subset of the finance and HR departments, respectively, plus senior management. On the other hand, sales pipeline data may be shared with production, operations, and supply chain to help forecast future capacity. The difference in audience scope often translates into how data is disseminated. Important data tends to originate from limited sources, like dedicated systems, whereas less critical data, like sales or product information, can be generated on the fly in a multitude of formats and channels, like email or Teams. Organizations with good data governance practices are unlikely to share critical information over Slack or WhatsApp

Static scopes, while easy to set up, have limitations. They are defined in very broad yet specific terms. When you define a static scope, you include an entire location, like OneDrive accounts, SharePoint sites, Exchange, or Microsoft 365 group mailboxes. Within those locations, individual items are explicitly specified to include or exclude. If an organization has considered scope scenarios when deploying mailboxes, then static scopes will be less of a headache to set up. 

However, when targeting individuals, static scope maintenance is manually intensive.  An adaptive scope operates on the same locations, more or less, but uses queries to specify which items are in scope. The queries use items’ attributes or properties to determine scope inclusion. Instead of specifying the HR manager by name as you would with a static scope, you would say, “where user attribute department equals HR and title equals manager.” An adaptive scope is applied to or associated with a policy to determine its reach in place of a static scope.

Currently, there are three adaptive scope categories. Users which operate on Azure Active Directory attributes. Sites, which uses SharePoint sites’ properties, and Microsoft 365 groups, which also makes use of some Active Directory attributes. You can associate multiple adaptive scopes with one policy to achieve coverage across all three categories or locations.