13.3 Data Loss Prevention (DLP) Policies & Connector Classifications

Data Loss Prevention (DLP) Policies & Connector Classifications

In the Microsoft Power Platform, Data Loss Prevention (DLP) policies provide the foundational data exfiltration defense across Power Apps (canvas and model-driven), Power Automate cloud flows, and Microsoft Copilot Studio. With over 1,000 pre-built first-party and third-party connectors available on the platform, DLP policies enforce strict rules governing which services can share data with one another, preventing proprietary corporate data from accidentally or maliciously leaking into consumer or public external endpoints.

---

1. DLP Architecture, Scopes & Precedence Rules

DLP policies are created and managed in the Power Platform Admin Center by Power Platform Administrators or Microsoft Entra Global Administrators. They evaluate connector usage at both design time (when a maker saves an app or flow) and runtime (when an automation executes).

+-----------------------------------------------------------------------------------+
|                         DLP POLICY SCOPING ARCHITECTURE                           |
|                                                                                   |
|  [1. TENANT-WIDE SCOPE (ALL ENVIRONMENTS)]                                        |
|  - Automatically covers all existing and future environments                      |
|  - Forms the mandatory baseline organizational security posture                   |
|                                                                                   |
|  [2. MULTIPLE ENVIRONMENTS (INCLUDE SPECIFIC)]                                    |
|  - Targets designated environments (e.g., "Finance Prod", "HR Sandbox")          |
|                                                                                   |
|  [3. EXCLUDE SPECIFIC ENVIRONMENTS]                                               |
|  - Covers all environments EXCEPT designated exempt containers                    |
+-----------------------------------------------------------------------------------+

DLP Scoping Tiers

1. Tenant-Wide (All Environments): Applies globally across every environment in the tenant, including all current environments and any new environments provisioned in the future. This creates an unshakeable corporate baseline.
2. Include Specific Environments (Multiple Environments): Restricts the policy's evaluation strictly to an explicitly enumerated list of environments (e.g., applying strict banking rules only to financial production environments).
3. Exclude Specific Environments: Applies across the entire tenant while exempting specific, highly governed integration environments that require unique connector combinations.

Multi-Policy Precedence & Conflict Resolution

An individual environment can be—and frequently is—governed by multiple overlapping DLP policies (for instance, a Tenant-wide baseline policy plus an Environment-specific department policy).

+-----------------------------------------------------------------------------------+
|                    MULTI-POLICY PRECEDENCE: MOST RESTRICTIVE WINS                 |
|                                                                                   |
|   POLICY A (Tenant Baseline):  SQL Server ===> Classified as [BUSINESS]           |
|   POLICY B (Finance Sandbox):  SQL Server ===> Classified as [BLOCKED]            |
|                                                                                   |
|   =============================================================================   |
|   EFFECTIVE RESULT IN FINANCE SANDBOX: SQL Server is [BLOCKED]                    |
|   (The most restrictive classification rule always wins in conflict evaluation)   |
+-----------------------------------------------------------------------------------+

[!IMPORTANT] The Restrictive Hierarchy Rule: When multiple DLP policies target the same environment and classify the same connector into different tiers, the most restrictive classification wins:

• Blocked is more restrictive than Business or Non-Business.
• If one policy classifies a connector as Business and another policy classifies it as Non-Business, the connector is effectively isolated and cannot share data with either group in that environment.

---

2. Connector Classification Data Groups

Every connector in the Power Platform catalog—including custom connectors—must belong to exactly one of three data classification groups within a given DLP policy:

+-----------------------------------------------------------------------------------+
|                      THE THREE CONNECTOR DATA CLASSIFICATIONS                     |
|                                                                                   |
|  +--------------------------------+      +-------------------------------------+  |
|  | BUSINESS GROUP (Confidential)  |      | NON-BUSINESS GROUP (Consumer/Public)|  |
|  | - Microsoft Dataverse          |      | - Twitter / X                       |
|  | - SharePoint Online            |      | - Facebook / Instagram              |
|  | - Office 365 Outlook           |      | - Gmail / Google Drive              |
|  | - SQL Server / Oracle          |      | - Dropbox / Trello                  |
|  | - SAP ERP / Salesforce         |      | - Consumer RSS Feeds                |
|  +--------------------------------+      +-------------------------------------+  |
|                 \                                  /                              |
|                  \============ CANNOT ============/                               |
|                   \=== COMMUNICATE OR SHARE =====/                                |
|                    \===== DATA TOGETHER ========/                                 |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | BLOCKED GROUP (Prohibited from all use in the scoped environment)           |  |
|  | - Anonymous FTP, Unauthorized Public Webhooks, Commercial File Sharing       |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

1. Business Data Group

• Purpose: Reserved for connectors that interact with sensitive, proprietary, internal enterprise business data.
• Typical Connectors: Microsoft Dataverse, SharePoint, Office 365 Users, Exchange/Outlook, SQL Server, Dynamics 365, SAP, Azure Blob Storage, Salesforce.

2. Non-Business Data Group (General / Consumer)

• Purpose: Reserved for connectors that interact with personal productivity tools, consumer services, public social media networks, and external services.
• Typical Connectors: Twitter/X, Facebook, YouTube, Gmail, Google Drive, Personal OneDrive, Trello, Dropbox, Yahoo Mail.

3. Blocked Data Group

• Purpose: Connectors placed in the Blocked group are entirely prohibited from being used in any Power App, Power Automate flow, or Copilot Studio chatbot within the scoped environment.
• Non-Blockable Core Services: Certain core first-party Microsoft services (such as Microsoft Dataverse, Office 365 Users, and Microsoft Entra ID) cannot be placed in the Blocked group because doing so would break fundamental platform authentication and base system features. However, they can be freely moved between Business and Non-Business.

The Core Enforcement Principle

• Within the Same Group: Connectors within the Business group can freely exchange data with other Business connectors. Connectors within the Non-Business group can freely exchange data with other Non-Business connectors.
• Across Groups (The Isolation Boundary): Data CANNOT flow between the Business group and the Non-Business group within the same application or automation:
  • A Power Automate flow cannot trigger on a Business connector (e.g., Dataverse record created) and execute an action in a Non-Business connector (e.g., Post a Tweet or Write to Google Drive).
  • A Power Apps canvas app cannot bind to data sources from both the Business group and Non-Business group simultaneously.

---

3. Granular Connector Action Controls

Historically, DLP policies operated as an all-or-nothing switch per connector. If an organization allowed the SQL Server or Azure DevOps connector, makers had full access to all triggers and actions. Modern DLP introduces Granular Connector Action Control.

+-----------------------------------------------------------------------------------+
|                     GRANULAR CONNECTOR ACTION CONTROLS (SQL SERVER)               |
|                                                                                   |
|   [CONNECTOR: SQL SERVER] ---> OVERALL STATUS: [ALLOWED]                          |
|                                                                                   |
|   [ACTION RULES]:                                                                 |
|   - Action: "Get rows (V2)"          ===> [ALLOW] (Read permitted)                |
|   - Action: "Get row (V2)"           ===> [ALLOW] (Read permitted)                |
|   - Action: "Execute query (V2)"     ===> [BLOCK] (Direct T-SQL blocked)          |
|   - Action: "Insert row (V2)"        ===> [BLOCK] (Writes blocked)                |
|   - Action: "Delete row (V2)"        ===> [BLOCK] (Deletes blocked)               |
+-----------------------------------------------------------------------------------+

Action-Level Mechanics

• Selective Operation Control: Administrators can permit a connector overall while selectively blocking specific individual triggers or actions within that connector.
• Read vs. Write Segregation: An enterprise can classify SQL Server or Oracle into the Business group while blocking all Insert, Update, Delete, or Execute Query actions. This enables citizen developers to build reporting dashboards and read-only lookup apps without granting them the ability to write to or corrupt production databases.
• Action-Level Precedence: If an action is blocked via granular control, any flow attempting to execute that specific action is blocked at design time, even if the parent connector is classified as Business.

---

4. Endpoint Filtering & Custom Connector Governance

For protocol-level and configurable connectors (such as the generic HTTP, HTTP with Microsoft Entra ID, and Custom Connectors), data exfiltration risks often depend on the destination web address.

+-----------------------------------------------------------------------------------+
|                         HTTP ENDPOINT FILTERING RULES                             |
|                                                                                   |
|   ORDER  |  PATTERN MATCH                   |  BEHAVIOR                           |
|   -------+----------------------------------+----------------------------------   |
|     1    |  https://api.contoso.com/*       |  [ALLOW] (Corporate ERP endpoint)   |
|     2    |  https://*.internal.azure.com/*  |  [ALLOW] (Internal Azure APIs)      |
|     3    |  *                               |  [DENY]  (All other web endpoints)  |
+-----------------------------------------------------------------------------------+

Endpoint Filtering Mechanics

• Domain & URL Allow/Deny Lists: Administrators can configure endpoint filtering on HTTP connectors and SQL connectors using URL pattern matching.
• Wildcard Support: Supports standard wildcard syntax (e.g., https://api.partner.com/* or https://*.contoso.com/*).
• Rule Evaluation Order: Rules are evaluated sequentially in order. The first matching pattern dictates whether the outbound request is allowed or blocked. Placing a wildcard * with a Deny action at the bottom of the rule list creates a zero-trust, allowlist-only architecture.

Custom Connector Governance

• Default Custom Connector Classification: Administrators can configure the default data group for newly authored custom connectors (Business, Non-Business, or Blocked).
• Host-Level Filtering: DLP policies can inspect the OpenAPI/Swagger definition of custom connectors and enforce endpoint filtering based on the target hostname.

Design-Time vs. Runtime Enforcement

• Design Time: When a maker attempts to save a flow or publish a canvas app that violates a DLP policy, the designer immediately displays a validation error detailing the conflicting connectors and blocks the save.
• Runtime Suspension: If an administrator creates or modifies a DLP policy that impacts existing active flows, Dataverse immediately flags the violating flows and suspends them from executing until the author resolves the connector conflict.

[!TIP] DLP Impact Analysis (Power Platform DLP Editor / CoE Starter Kit): Always run DLP impact analysis using the Center of Excellence (CoE) Starter Kit or PPAC impact review before applying restrictive DLP policy changes to production environments, ensuring that existing business-critical automations are not unintentionally suspended.