Exercise - Design a layered data policy strategy

  • 45 minutes

In this exercise, you design and document a layered data policy strategy for Zava's Power Platform tenant. Rather than configuring policies in the Power Platform admin center, you apply the concepts from this module to produce a written governance framework. These concepts include connector classification, action-level controls, Copilot Studio governance, and multi-policy layering.

Your deliverable is a structured design document (written notes, a markdown file, or a table format of your choice) that captures your policy decisions and reasoning. This is the kind of artifact a real governance team would produce before implementing data policies in a production tenant.

This exercise should take approximately 45 minutes to complete.

Prerequisites

To complete this exercise, you need:

  • A text editor or note-taking tool for documenting your design decisions
  • Familiarity with the concepts covered in this module (connector classification, action-level controls, endpoint filtering, virtual connectors, desktop flow governance, and multi-policy layering)

Scenario

Zava's Power Platform admin team needs to implement data policies that achieve these goals:

  • Protect Zava Pay customer financial data from flowing to unapproved services.
  • Allow marketing makers to use a broad set of connectors for campaigns and content.
  • Ensure Copilot Studio agents only use approved knowledge sources in regulated environments.
  • Accommodate future connector additions without creating governance gaps.

The tenant has three environment groups aligned to the zoned governance model:

Zone Environments Purpose
Green zone Personal productivity and marketing sandboxes Low-risk exploration and campaign work
Yellow zone Department-level shared development and test Collaborative app building with moderate controls
Red zone Zava Pay production, Zava Pay test, other regulated production PCI-DSS regulated workloads requiring strict controls

Note

There is no single "correct" answer for this exercise. The goal is to produce a defensible design with clear reasoning. Different organizations would make different classification decisions based on their risk tolerance and business needs.

Design the tenant-wide baseline policy

The baseline policy applies to all environments in the tenant and establishes the default governance posture. It prevents data leakage between organizational and non-organizational services regardless of which zone an environment belongs to.

  • Identify at least five connectors that belong in the Business group - connectors that handle organizational data and should only share data with each other. Consider connectors like Dataverse, SharePoint, Office 365 Outlook, Office 365 Users, and Dynamics 365.
  • Identify at least three connectors that should be Blocked across the entire tenant. Consider social media connectors, personal email services, or file-sharing services that pose data-exfiltration risk.
  • Determine the appropriate default classification for the * wildcard rule that governs custom connectors and any newly added connectors. Document whether new connectors should default to Non-Business or Blocked, and explain your reasoning.
  • For each classification decision, write a one-sentence justification that references business risk or compliance requirements.

Tip

When deciding the wildcard default, consider what happens when Microsoft adds a new connector to the platform. A "Non-Business" default allows makers to use it immediately but prevents data mixing with Business connectors. A "Blocked" default requires admin review before any new connector is usable.

Design Red-zone restrictions for Zava Pay

The Red-zone policy is scoped only to Zava Pay production and test environments. It layers additional restrictions on top of the tenant baseline to meet PCI-DSS requirements.

Restrict connectors and endpoints

  1. Identify at least three connectors that are acceptable in Green/Yellow zones but must be blocked in Red-zone environments. Consider connectors that could exfiltrate payment card data to external services.
  2. Configure endpoint filtering rules for the HTTP connector. Specify that only the following endpoints are allowed:
    • https://api.zava.com/*
    • https://payments.zava.com/*
  3. Document why unrestricted HTTP access is unacceptable in a PCI-regulated environment.

Define action-level controls

  1. Specify action-level controls for the SharePoint connector: allow read actions (Get items, Get file content) but block delete actions (Delete item, Delete file).
  2. Set the default posture for new actions to Block on all connectors in this policy. Explain how this prevents governance drift when connectors gain new capabilities.
  3. Identify one additional connector where action-level controls (rather than full blocking) would benefit Zava Pay makers, and document which actions to allow and which to block.

Configure Copilot Studio controls

Define data controls for Copilot Studio agents in the Red-zone environments. These controls use virtual connectors to govern what knowledge sources and channels agents can access.

  1. Determine which knowledge source virtual connectors to block in Zava Pay environments. Consider whether agents should be allowed to use Bing Web Search, public websites, or uploaded documents as knowledge sources.
  2. Determine which knowledge source virtual connectors to allow. Consider SharePoint and Dataverse as approved organizational knowledge sources.
  3. Configure endpoint filtering for the SharePoint knowledge virtual connector to restrict agents to:
    • https://zava.sharepoint.com/sites/zavapay-kb/*
  4. Specify which publishing channels are allowed for agents in Zava Pay environments (for example: Teams only, or Teams and internal websites). Block channels that could expose regulated data externally.
  5. Document how these Copilot Studio controls interact with the tenant baseline and Red-zone connector policies. Identify whether any conflicts exist and which policy wins.

Plan desktop flow governance

Define desktop flow governance for Zava Pay environments. Desktop flow module controls restrict which local system actions Power Automate desktop flows can perform.

  1. Identify at least three desktop flow modules that should be blocked in regulated environments. Consider modules that interact with external email clients, web browsers, or the local file system in ways that could bypass cloud DLP controls.
  2. Identify the modules that remain available and document why they are necessary for Zava Pay automation scenarios (for example: Excel automation for report generation, or system interaction for legacy application integration).
  3. Document the enforcement timing for desktop flows that use child flows. Explain when DLP evaluation occurs and what happens if a parent flow calls a child flow that uses a blocked module.

Note

Remember Desktop flow DLP controls are evaluated at run time, not design time. A flow that was previously compliant can fail if policy changes block a module it uses. Your design should account for how to communicate policy changes to makers.

Document the combined policy effect

Create a summary that captures the combined effect of all policy layers. This section serves as a reference for the admin team and for compliance audits.

  1. Create a table showing the effective governance for each zone. Use a format similar to:

    Connector Green zone Yellow zone Red zone
    (example) SharePoint Business (all actions) Business (all actions) Business (read only)
    (example) HTTP Non-Business (all endpoints) Non-Business (all endpoints) Business (restricted endpoints)
    (add rows)

  2. Describe what happens when a new connector is added to Power Platform. For each policy layer, explain whether the connector is usable, blocked, or restricted by default.

  3. Define a quarterly review process that includes: who evaluates new connectors, what criteria they use for classification, and how maker requests for unblocking a connector are handled.

  4. Document the escalation path when a maker in a Red-zone environment needs access to a currently blocked connector or action.

Success criteria

Your data policy strategy design is complete when:

  • A tenant-wide baseline policy classifies connectors into Business, Non-Business, and Blocked groups with documented reasoning.
  • Red-zone environments have additional restrictions including endpoint filtering and action-level controls appropriate for PCI-regulated workloads.
  • Copilot Studio agents are limited to approved knowledge sources and publishing channels in regulated environments.
  • Desktop flow modules are governed in regulated environments with enforcement timing documented.
  • The combined effect of all policies is captured in a summary table showing per-zone governance.
  • A process exists for handling new connectors, maker requests, and quarterly reviews.