# Control 2.1: Managed Environments

**Control ID:** 2.1<br>
**Pillar:** Management<br>
**Regulatory Reference:** FINRA Rule 3110 (Supervision), FINRA Rule 4511 (Books and Records), FINRA Regulatory Notice 24-09 (Gen AI guidance), SEC Rules 17a-3/17a-4 (Recordkeeping), SOX Sections 302/404 (Internal Controls), GLBA 501(b) (Safeguards Rule), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) (Technology Risk Management), Federal Reserve SR 26-2 (formerly SR 11-7) (Model Risk), NYDFS 23 NYCRR 500.06 (Audit Trail), FFIEC IT Examination Handbook (IT Risk Management)<br>
**Last UI Verified:** April 2026<br>
**Governance Levels:** Baseline / Recommended / Regulated<br>

---

!!! info "Agent 365 Architecture Update"
    Agent 365 lifecycle management complements Power Platform Managed Environments by providing cross-platform promotion gates and approval workflows. While Managed Environments continue to govern Microsoft Copilot Studio agents, Agent 365 extends lifecycle governance to Agent Builder, Microsoft Foundry, and SharePoint agents. See [Unified Agent Governance](../../framework/agent-identity-architecture.md) for lifecycle management architecture.

## Objective

Enable premium governance capabilities for Power Platform environments by designating them as Managed Environments, providing enhanced control over sharing, solution deployment, usage monitoring, and maker onboarding essential for financial services governance.

---

## Why This Matters for FSI

- **FINRA 4511, FINRA RN 24-09 / Rule 3110:** Usage insights and activity logs help support books-and-records evidence collection. Managed Environments alone do not satisfy 4511 — pair with retention (Control 1.7) and Purview audit (Control 3.1).
- **SEC 17a-3 (record creation):** Solution checker enforcement helps establish change-control evidence for systems that create regulated records. (SEC 17a-4 is the WORM-preservation requirement and is addressed by Control 1.7 retention policies, not by Managed Environments.)
- **GLBA 501(b):** Sharing limits and Tenant Isolation help reduce the surface area for unauthorized access to customer information.
- **SOX 302 / SOX 404:** Maker welcome content and access reviews aid in documenting policy acknowledgment and access governance for internal controls over financial reporting.
- **Federal Reserve SR 26-2 (formerly SR 11-7) (model risk):** Solution checker, sharing limits, and access reviews contribute to the change-control and access-governance pieces of a model-risk framework.

---

!!! danger "Non-substitution — technical guardrails are not governance"
    Managed Environments provide **technical guardrails** (sharing limits, solution-checker enforcement, IP firewall, usage insights). They **do not replace**:

    - **Model-risk governance committee oversight** required by OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Federal Reserve SR 26-2 (formerly SR 11-7) — see [Control 2.6](2.6-model-risk-management-sr-26-2.md). A Managed Environment toggle is not an independent model validation.
    - **Supervisory review by an appropriately registered principal** required by FINRA Rule 3110 — see [Control 2.12](2.12-supervision-and-oversight-finra-rule-3110.md). Solution-checker enforcement is not a Series-24 sign-off.
    - **Books-and-records retention** required by FINRA 4511 / SEC 17a-4 — see [Control 1.7](../pillar-1-security/1.7-comprehensive-audit-logging-and-compliance.md) and [Control 3.1](../pillar-3-reporting/3.1-agent-inventory-and-metadata-management.md). The weekly digest is operational telemetry, not a regulated record.
    - **Written Supervisory Procedures** documenting who reviews what, when, and how. Examiners will hold the firm to its own WSPs.

    Treat Managed Environments as the **enforcement substrate** that makes the human-and-process controls above operable and auditable.

!!! warning "Sovereign Cloud Availability — GCC, GCC High, DoD, China"
    Managed Environments are available in sovereign clouds with **material feature gaps** that affect FSI evidence pipelines:

    - **Usage insights / weekly digest:** **Not available** in GCC, GCC High, DoD, or Power Platform / Dynamics 365 services in China ([Learn — Usage insights](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-usage-insights)). FSI tenants in these clouds **cannot rely on the weekly digest as books-and-records evidence** and must substitute Microsoft Graph activity exports, Purview audit ([Control 1.7](../pillar-1-security/1.7-comprehensive-audit-logging-and-compliance.md) / [Control 3.1](../pillar-3-reporting/3.1-agent-inventory-and-metadata-management.md)), or Sentinel ingestion ([Control 3.9](../pillar-3-reporting/3.9-microsoft-sentinel-integration.md)).
    - **Customer-Managed Keys (CMK):** Service coverage differs between commercial and GCC High. Several services that CMK-encrypt in commercial (e.g., Power Automate, several Dynamics 365 apps) are not yet on the GCC High CMK list. Verify per-service coverage in [Learn — Customer-managed key](https://learn.microsoft.com/en-us/power-platform/admin/customer-managed-key) before asserting CMK coverage in your control narrative.
    - **Agent 365 governance console:** Not yet at parity for GCC, GCC High, or DoD as of GA. See [Control 2.25](2.25-agent-365-admin-center-governance-console.md) for the compensating-control pattern (named owner in 1.2 registry, manual quarterly attestation, change-management approval per 2.3, SoD per 2.8) and disclose the gap in your Written Supervisory Procedures.

    Re-verify sovereign-cloud parity quarterly via the [Microsoft 365 Government roadmap](https://aka.ms/m365gov-roadmap) and the linked Learn pages.

---

!!! tip "Automation Available"
    Companion solutions in [FSI-AgentGov-Solutions](https://github.com/judeper/FSI-AgentGov-Solutions):

    - [Environment Lifecycle Management](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/environment-lifecycle-management) — automated Power Platform environment provisioning with zone-based governance
    - [Segregation Detector](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/segregation-detector) — role conflict detection for Maker/Checker enforcement in agent pipelines
    - [DR Testing Framework](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/dr-testing-framework) — automated disaster recovery testing for AI agent infrastructure


## Prerequisites

!!! warning "Licensing Requirements"
    Managed Environments require **Power Platform Premium capacity** or equivalent licensing. Verify the following before implementation:

    - **Managed Environment activation**: Requires Power Apps, Power Automate, or Copilot Studio premium licenses, OR Dynamics 365 licenses, OR Power Platform per-app/per-user plans with premium entitlements
    - **Advanced security features** (IP Firewall, VNet, CMK, Lockbox): Require additional licensing beyond Managed Environment designation
    - **Usage insights**: Included with Managed Environment; no additional license required
    - **Solution checker enforcement**: Included with Managed Environment; no additional license required

    Consult [Microsoft Learn: Licensing overview](https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus) for current licensing requirements.

!!! danger "Pay-As-You-Go Does NOT Satisfy Managed Environment Licensing"
    Enabling pay-as-you-go for a Managed Environment is **NOT sufficient** to meet licensing requirements if:

    - Users without standalone Power Apps licenses are using Power Apps in that environment, OR
    - Users without standalone Power Automate licenses are using flows in that environment

    Pay-as-you-go billing alone does not satisfy Managed Environment licensing where users otherwise lack qualifying entitlement. Each active user needs a qualifying premium per-user entitlement, or the environment must have applicable capacity-based license rights. Administrators should also review Managed Environment license-consumption reports (PPAC > Resources > License consumption) and Microsoft's 2026 compliance notifications.

    **Enforcement timeline (June 2026):** Microsoft begins user-facing in-app notifications for unlicensed users in Managed Environments and admin alerts in PPAC + Message Center starting June 2026. Run a license-coverage audit **before** June 2026 to avoid maker-facing disruption.

    **Source:** [Microsoft Learn: Managed Environments Licensing](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-licensing)

---

## Pipeline Targets and Managed Environments

!!! warning "Pipeline target environments — verify current Microsoft guidance before relying on auto-enablement"
    The Power Platform Pipelines feature has historically required (or strongly recommended) that pipeline target environments be Managed Environments. Microsoft has indicated tightening of this expectation through 2026, but the exact mechanism (admin opt-in vs auto-enable) and date have shifted in successive Learn updates.

    **Verified action regardless of Microsoft's enforcement timing:**

    1. Audit all pipeline target environments in your tenant.
    2. Verify premium-licensing coverage for each target environment ([Learn — Managed Environment Licensing](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-licensing)).
    3. **Proactively** enable Managed Environment status on all pipeline targets so you control timing and evidence collection.
    4. Use [Pipeline Governance Cleanup](../../reference/solutions-index.md#pipeline-governance-cleanup) to discover and remediate personal pipelines.

    **Sources to re-check before quoting a date:**

    - [Microsoft Learn — Admin Deployment Hub](https://learn.microsoft.com/en-us/power-platform/alm/admin-deployment-hub)
    - [Microsoft Learn — Managed Environment Licensing](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-licensing)
    - Microsoft 365 Roadmap and Message Center for the latest enforcement window.

---

## Control Description

Managed Environments provide premium governance capabilities for Power Platform environments, enabling centralized control over sharing, solution deployment, usage insights, and maker onboarding. When enabled, administrators gain access to governance capabilities including sharing controls, solution checker enforcement, usage insights, maker welcome content, and cross-tenant restrictions. Advanced security features such as IP Firewall, VNet support, Customer Managed Keys, and Lockbox require separate licensing and configuration beyond the Managed Environment designation.

For FSI organizations, Managed Environments are essential for enforcing governance policies at the environment level. The feature enables a "sterile default" strategy where all non-personal environments operate under controlled sharing, monitored usage, and enforced deployment gates.

Key capabilities particularly relevant for regulated financial services include:

- **Manage sharing** - Limit how widely apps, flows, and agents can be shared
- **Solution checker enforcement** - Block/warn on solution imports with security issues
- **Usage insights** - Weekly digest of top apps and flows for compliance monitoring
- **Maker welcome content** - Custom onboarding guidance communicating policy requirements
- **Cross-tenant restrictions** - Control connector access across tenant boundaries

### Customer Lockbox & Data Residency Posture

**Sub-control scope.** This sub-section consolidates the Customer Lockbox (CL) and data-residency posture for tenants running Microsoft 365 AI agents and Power Platform workloads. It is intentionally implemented as an extension of Control 2.1 rather than a standalone control because Lockbox approval workflow, Multi-Geo placement, and Power Platform CMK / VNet posture all sit on top of the Managed Environment substrate. Cross-references in Controls [1.5](../pillar-1-security/1.5-data-loss-prevention-dlp-and-sensitivity-labels.md), [1.6](../pillar-1-security/1.6-microsoft-purview-dspm-for-ai.md), [1.13](../pillar-1-security/1.13-sensitive-information-types-sits-and-pattern-recognition.md), [1.15](../pillar-1-security/1.15-encryption-data-in-transit-and-at-rest.md), and [3.7](../pillar-3-reporting/3.7-ppac-security-posture-assessment.md) point back here.

**Customer Lockbox — what it gates.** Customer Lockbox provides an in-tenant approval workflow for Microsoft engineer access to customer data. When a Microsoft support engineer needs to access tenant content to resolve a service request, the Lockbox approver receives an email request that must be approved or denied within a fixed window before access is granted. Lockbox is available for Microsoft 365 (Exchange Online, SharePoint Online, OneDrive for Business, Teams), Power Platform (Dataverse data plane), and selected Azure services (Storage, SQL Database, VMs). Coverage is per-service — verify against [Microsoft Learn — Customer Lockbox supported services](https://learn.microsoft.com/en-us/purview/customer-lockbox-requests) before asserting Lockbox coverage for a workload.

!!! danger "Agent 365 audit-logging path is NOT covered by Customer Lockbox"
    Microsoft engineer access to the **Agent 365 audit-logging plane** (the back-end pipeline that ingests Agent 365 activity events into the unified audit log) is **not gated by Customer Lockbox** as of GA. Microsoft can access the audit-logging metadata for service-operations and abuse-investigation purposes without an in-tenant Lockbox approval. This is a known gap that customers must document in their Written Supervisory Procedures and vendor-risk register.

    **Compensating controls:**

    - Treat Agent 365 audit-event payloads as **service-operations metadata** rather than fully customer-controlled records. Where examiners require evidence of who-saw-what, supplement Agent 365 audit data with [Control 1.7](../pillar-1-security/1.7-comprehensive-audit-logging-and-compliance.md) Purview Audit (Premium) records and [Control 3.9](../pillar-3-reporting/3.9-microsoft-sentinel-integration.md) Sentinel ingestion, both of which surface Lockbox-gated underlying data plane events.
    - Disclose this Lockbox-coverage gap in the firm's [Control 2.7](2.7-vendor-and-third-party-risk-management.md) vendor-risk file and the cloud-provider attestation pack pulled from the [Service Trust Portal Attestation Guide](../../reference/service-trust-portal-attestation-guide.md).
    - Re-verify the Lockbox coverage matrix at each Microsoft service-update cycle; Microsoft has signalled progressive expansion of Lockbox coverage post-GA but no firm date is available.

**Data residency — where customer content sits.** Three independent residency surfaces affect AI agent grounding sources:

1. **Microsoft 365 Multi-Geo.** A licensed feature that allows a single Microsoft 365 tenant to store user mailbox, OneDrive, and SharePoint data in multiple geographies (`Geos`) under a single tenancy. Required where business units operate under different regional regulators (e.g., a US tenant with EU subsidiary mailbox/OneDrive content pinned to the EU Geo for GDPR reasons). Configure via PPAC + Microsoft 365 Admin Center with the **Multi-Geo Capabilities** add-on.
2. **Azure regional pinning (for Power Platform / Dataverse).** Each Power Platform environment is created in a single Azure region; the Dataverse data, Customer Key vaults, and most stateful Power Platform services remain in that region. Use **Environment Routing** (Section 4 above) to direct new environments into the correct regional bucket per business-unit residency rules.
3. **EU Data Boundary (EUDB).** Microsoft's commitment to store and process customer data and personal identifying data for EU/EFTA customers within the EU Data Boundary, including Microsoft 365, Dynamics 365, Power Platform, and most Azure services. As of January 2025, EUDB Phase 3 covers Professional Services data and most service-generated logs. EUDB is the right answer for FSI subsidiaries operating in EU member states; for US-only tenants it is not directly applicable, but the EUDB documentation is the authoritative source for Microsoft's residency commitments and incident-notification posture.

**FSI implications.**

- **GLBA 501(b) (Safeguards Rule).** Customer Lockbox helps support the "administrative safeguards" element of 501(b) by giving the firm a documented, in-tenant approval point for any Microsoft engineer access to non-public customer information. The Lockbox approval/denial record (M365 Admin Center → Customer Lockbox history) is retained as part of the firm's vendor-access evidence pack. Lockbox alone does not satisfy 501(b) — pair with [Control 1.7](../pillar-1-security/1.7-comprehensive-audit-logging-and-compliance.md), [Control 2.7](2.7-vendor-and-third-party-risk-management.md), and the firm's written information security program.
- **FINRA Rule 4511 (Books and Records) record-residency.** FINRA does not currently mandate a specific geographic residency for electronic records, but firms with multi-jurisdictional operations must be able to produce records on demand in the jurisdictions in which they operate. Multi-Geo and Azure regional pinning aid in establishing that the firm can satisfy a non-US regulator's records-production request without breaching local data-export rules. Document the residency mapping in the records-retention schedule that accompanies [Control 1.7](../pillar-1-security/1.7-comprehensive-audit-logging-and-compliance.md).
- **NYDFS 23 NYCRR 500.05 / 500.06 (Penetration Testing & Audit Trail).** New York-licensed firms must maintain audit trails of access to non-public information. Lockbox approval evidence is a required input to the firm's 500.06 audit-trail evidence pack. Where Agent 365 audit-logging is in scope, document the Lockbox-coverage gap above as a compensating-control note in the 500.06 audit narrative.
- **State-level AI / privacy laws.** Several US state AI laws (Colorado SB24-205, Texas TRAIGA, NYC LL144) and consumer-privacy laws (CCPA/CPRA, VCDPA) include vendor-access disclosure and data-localization elements that can be partially evidenced by Lockbox approvals and Multi-Geo placement. Map specific obligations against the residency posture in the firm's privacy-impact assessment.

---

## Key Configuration Points

### Managed Environment Settings

- Enable Managed Environment status for all non-personal environments
- Configure sharing limits per resource type (Power Apps, Power Automate, Copilot Studio)
- Set solution checker enforcement level: None (Zone 1), Warn (Zone 2), Block (Zone 3)
- Enable usage insights with Compliance team as additional recipients
- Configure maker welcome content with governance policy summary and policy links
- Apply cross-tenant restrictions (disable inbound/outbound for regulated environments)
- Configure the **IP Firewall** (Zone 3) to restrict access to Power Platform services from allow-listed CIDR ranges
- Configure **IP cookie binding** (Zone 3) to bind user sessions to source IP, reducing session-token-replay risk
- Configure **Customer-Managed Keys (CMK)** for environments that hold regulated data, where your KMS posture requires it (additional licensing applies)
- Enable **Customer Lockbox** for in-tenant approval of any Microsoft engineer access to environment data (additional licensing applies)

### Customer Lockbox Enablement (per Sub-Control above)

- **M365 tenant surface:** M365 Admin Center → **Settings** → **Org settings** → **Security & privacy** → **Customer Lockbox** → toggle **Require approval for all data access requests** to **On** and assign the **Customer Lockbox access approver** role group to the named approvers (minimum two named individuals + one role mailbox; treat as a privileged role, segregated from day-to-day administration).
- **Power Platform surface:** PPAC → **Tenant Settings** → confirm Customer Lockbox is enabled for Power Platform (per-environment scope where supported). The Power Platform Lockbox toggle is independent from the M365 toggle — both must be on for Dataverse data-plane Lockbox coverage.
- **Azure surface:** For Azure-resident workloads (Azure Storage hosting agent grounding sources, Azure SQL evaluation databases), enable Customer Lockbox in the Azure portal under each subscription's **Customer Lockbox** blade and assign approvers per subscription.
- **Approver hardening:** Enforce phishing-resistant MFA on every approver account (Authenticator + FIDO2 minimum), require Conditional Access named-location restrictions on Lockbox approval mailbox sign-in, and route Lockbox-decision audit events into Sentinel ([Control 3.9](../pillar-3-reporting/3.9-microsoft-sentinel-integration.md)) for SOC visibility.
- **Quarterly Lockbox-path test:** Coordinate with the Microsoft FastTrack / CSAM contact to initiate a benign Lockbox test request each quarter; capture the approval evidence and retain in the privileged-access governance pack. Document approver-rotation cadence in the firm's Written Supervisory Procedures.
- **Sovereign cloud caveat:** Lockbox availability and operational behavior may differ in 21Vianet (China) and certain GCC High / DoD sub-services — re-verify per the [Sovereign Cloud Availability](#agent-365-blueprint-lifecycle-preview) guidance above.

### Data Residency Configuration (per Sub-Control above)

- **Microsoft 365 Multi-Geo:** Enable the Multi-Geo add-on (separate license SKU) and assign each user to the appropriate `PreferredDataLocation` (PDL) at the time of license assignment. Verify Multi-Geo placement via Microsoft 365 Admin Center → **Setup** → **Multi-Geo Capabilities** and per-user via `Get-MsolUser -UserPrincipalName ... | Select PreferredDataLocation`. Document PDL assignment rules in the firm's data-residency policy and re-verify annually.
- **Azure / Power Platform regional pinning:** Use [Environment Routing](#environment-provisioning-governance) to direct new environments into the Azure region(s) that align with the firm's residency rules. For environments holding regulated content, pin Customer Key vaults ([Control 1.15](../pillar-1-security/1.15-encryption-data-in-transit-and-at-rest.md)) to the same region (and a paired region for redundancy) — cross-region key custody complicates regulator records-production scenarios.
- **EU Data Boundary applicability:** Where the firm has EU/EFTA subsidiaries or processes EU customer data, document EU Data Boundary applicability per Microsoft's published [EU Data Boundary commitment](https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn) and map the in-scope Microsoft services to the firm's GDPR records-of-processing inventory.
- **Residency exception register:** Maintain an exception register for any agent grounding source, Copilot Studio environment, or Power Platform connector that does not align with the firm's primary residency rules. Each exception must carry a documented business rationale, a compensating control, and an annual re-validation date.

### Environment Provisioning Governance

- **Restrict environment creation to authorized admins:** In Power Platform Admin Center > Tenant Settings, configure the following to "Only specific admins" for each environment type:
    - Developer environment assignments
    - Production environment assignments
    - Trial environment assignments
    
    This prevents uncontrolled environment sprawl where trial or developer environments may expose sensitive data or bypass compliance controls

- **Configure environment routing:** In PPAC > Tenant Settings > Environment Routing, configure routing rules to ensure new environments are created in the correct region aligned with data residency requirements and organizational governance policies. This supports compliance with data locality regulations and optimizes resource management

- **Enable tenant isolation:** In PPAC > Security > Identity and access > Tenant Isolation, enable "Restrict Cross-Tenant Connections" to prevent data from moving into or out of the tenant via Power Platform connectors. Configure explicit exceptions (by Tenant ID and direction) only for trusted partner tenants. Unrestricted cross-tenant connectivity increases risk of unintended data exchange and regulatory non-compliance

- **Configure environment security groups:** In PPAC > Security > Identity and access > Environment Security Groups, assign a security group to each environment to control user access. Without security groups, environment access may default to broad access, increasing risk of unauthorized access to sensitive data and applications

---

## Zone-Specific Requirements

| Zone | Requirement | Rationale |
|------|-------------|-----------|
| **Zone 1** (Personal) | Apply baseline minimum; document exceptions for personal agents; environment creation restricted to admins | Reduces risk from personal use while keeping friction low |
| **Zone 2** (Team) | Enable managed environment governance; require identified owner and approval trail; security groups required; tenant isolation enabled | Shared agents increase blast radius; controls must be consistently applied |
| **Zone 3** (Enterprise) | Require strictest configuration enforced via policy; treat changes as controlled; security groups required; tenant isolation enforced; environment routing configured for data residency compliance | Enterprise agents handle most sensitive content and highest regulatory risk |

---

## Roles & Responsibilities

| Role | Responsibility |
|------|----------------|
| Power Platform Admin (or Dynamics 365 Admin) | **Only these tenant-level roles** can enable / edit Managed Environments per [Learn — Permissions](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-enable#permissions). Configure environment settings, sharing limits, IP Firewall, CMK |
| Environment Admin | Environment-level user management; **cannot** change Managed Environments property |
| Delegated Admin | Delegated administration; **cannot** change Managed Environments property |
| Compliance Officer | Reviews usage insights; approves governance zone classifications; receives weekly digest |
| IT Governance | Defines sharing-limit policy, solution-checker enforcement level, IP-allow-list standards |
| AI Governance Lead | Configures agent-specific sharing settings within managed environments |

---

## Related Controls

| Control | Relationship |
|---------|--------------|
| [1.20 - Network Isolation](../pillar-1-security/1.20-network-isolation-private-connectivity.md) | VNet support implementation for private connectivity |
| [2.2 - Environment Groups](2.2-environment-groups-and-tier-classification.md) | Group-level governance rules that complement environment settings |
| [2.15 - Environment Routing](2.15-environment-routing.md) | Automatic maker placement into governed environments |
| [1.4 - Advanced Connector Policies](../pillar-1-security/1.4-advanced-connector-policies-acp.md) | Data policies enforced within managed environments |
| [2.3 - Change Management](2.3-change-management-and-release-planning.md) | Solution deployment controls using solution checker |
| [2.22 - Inactivity Timeout Enforcement](2.22-inactivity-timeout-enforcement.md) | Inactivity timeout policies operate within managed environment framework |
| [1.5 - DLP and Sensitivity Labels](../pillar-1-security/1.5-data-loss-prevention-dlp-and-sensitivity-labels.md) | Sensitivity-label-driven encryption is the only supported AI-app encryption path; Lockbox/CL caveats interact with label-based DLP for Copilot |
| [1.6 - DSPM for AI](../pillar-1-security/1.6-microsoft-purview-dspm-for-ai.md) | Agent 365 audit-logging Lockbox-coverage gap (see Customer Lockbox & Data Residency Posture sub-section) affects DSPM for AI evidence narrative |
| [1.13 - Sensitive Information Types](../pillar-1-security/1.13-sensitive-information-types-sits-and-pattern-recognition.md) | SITs that detect NPI/MNPI inherit the residency posture configured here |
| [1.15 - Encryption (Data in Transit / at Rest)](../pillar-1-security/1.15-encryption-data-in-transit-and-at-rest.md) | Customer Key vaults must be regionally co-located with the Power Platform environment per the data-residency configuration here |
| [3.7 - PPAC Security Posture Assessment](../pillar-3-reporting/3.7-ppac-security-posture-assessment.md) | Lockbox approval evidence and audit-logging-coverage gaps surface in the PPAC security-posture review pack |

---

## Implementation Playbooks

!!! info "Step-by-Step Implementation"

    This control has detailed playbooks for implementation, automation, testing, and troubleshooting:

    - [Portal Walkthrough](../../playbooks/control-implementations/2.1/portal-walkthrough.md) — Step-by-step portal configuration
    - [PowerShell Setup](../../playbooks/control-implementations/2.1/powershell-setup.md) — Automation scripts
    - [Verification & Testing](../../playbooks/control-implementations/2.1/verification-testing.md) — Test cases and evidence collection
    - [Troubleshooting](../../playbooks/control-implementations/2.1/troubleshooting.md) — Common issues and resolutions

!!! tip "Advanced Implementation: Configuration Hardening Baseline"

    This control is covered by the [Configuration Hardening Baseline](../../playbooks/advanced-implementations/configuration-hardening-baseline/index.md), which consolidates SSPM-detectable settings across all 7 mapped controls into a single reviewable checklist with automation classification and evidence export procedures.

---

## Verification Criteria

Confirm control effectiveness by verifying:

1. Managed Environment status shows enabled in PPAC environment details
2. Sharing limits block attempts to share beyond configured thresholds (test with non-admin user)
3. Solution checker blocks non-compliant solution imports (if Block mode enabled)
4. Weekly usage insights digest arrives at configured recipient addresses
5. Maker welcome content displays for new users accessing the environment
6. Environment creation is restricted to authorized admins only (PPAC > Tenant Settings > verify "Only specific admins" is set for Developer, Production, and Trial environment assignments)
7. Environment routing is configured for correct region (PPAC > Tenant Settings > Environment Routing)
8. Tenant isolation is enabled (PPAC > Security > Identity and access > Tenant Isolation > "Restrict Cross-Tenant Connections" is on)
9. Security groups are assigned to all Zone 2/3 environments (PPAC > Environment details > Security group)
10. License-entitlement coverage verified for every active maker (PPAC > Resources > License consumption)
11. IP Firewall allow-list reviewed against current corporate egress ranges (Zone 3)
12. Inactive-environment / quarantine notifications routed to the governance distribution list

---

## Additional Resources

- [Microsoft Learn: Managed Environments Overview](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-overview)
- [Microsoft Learn: Enable Managed Environment](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-enable)
- [Microsoft Learn: Sharing Limits](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-sharing-limits)
- [Microsoft Learn: Solution Checker Enforcement](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-solution-checker)
- [Microsoft Learn: Usage Insights](https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-usage-insights)
- [Microsoft Learn: Cross-tenant Restrictions](https://learn.microsoft.com/en-us/power-platform/admin/cross-tenant-restrictions)
- [Microsoft Learn: Customer Lockbox in Microsoft 365](https://learn.microsoft.com/en-us/purview/customer-lockbox-requests) — approver workflow, supported services, retention
- [Microsoft Learn: Customer Lockbox for Power Platform](https://learn.microsoft.com/en-us/power-platform/admin/about-lockbox) — Power Platform Lockbox enablement and per-environment scope
- [Microsoft Learn: Microsoft 365 Multi-Geo](https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-multi-geo) — Geos, PreferredDataLocation, licensing
- [Microsoft Learn: EU Data Boundary for Microsoft Cloud Services](https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn) — scope, services in scope, professional-services data
- [Microsoft Learn: Where is my Microsoft 365 data stored?](https://learn.microsoft.com/en-us/microsoft-365/enterprise/o365-data-locations) — per-Geo data-storage map for Microsoft 365 services

!!! tip "Advanced Implementation: Environment Lifecycle Management"
    For automated environment provisioning with Managed Environment status enabled from creation, see [Environment Lifecycle Management](../../playbooks/advanced-implementations/environment-lifecycle-management/index.md).

    **Deployable Solution:** [environment-lifecycle-management](https://github.com/judeper/FSI-AgentGov-Solutions/tree/main/environment-lifecycle-management) provides Python automation scripts for Dataverse schema creation, security roles, and evidence export.

## Agent 365 Blueprint Lifecycle (Preview)

!!! info "Agent 365 GA — May 2026"
    Microsoft Agent 365 reached general availability on May 1, 2026 (bundled in Microsoft 365 E7 or available as a standalone Microsoft Agent 365 per-user license). Agent Essentials category definitions and SDK feature scope continue to mature post-GA — verify current feature availability against Microsoft Learn before implementing production controls dependent on specific Agent 365 capabilities.

Agent 365 Blueprints introduce 3-phase lifecycle management that aligns with Managed Environment promotion paths:

- **Phase 1: Design** - Define agent requirements and governance zone
- **Phase 2: Build** - Develop in development Managed Environment
- **Phase 3: Deploy** - Promote to production Managed Environment via Blueprint registration

- [Microsoft Learn: Agent 365 Blueprint (Preview)](https://learn.microsoft.com/en-us/microsoft-365/copilot/agent-essentials/m365-agents-blueprint) - 3-phase deployment framework

---

!!! note "Implementation Note"
    Organizations should verify that their implementation meets their specific regulatory obligations. This control supports compliance efforts but requires proper configuration and ongoing validation.

*Updated: May 2026 | Version: v1.6.2 | UI Verification Status: Current*
