Skip to content

Control 1.20: Network Isolation and Private Connectivity

Control ID: 1.20
Pillar: Security
Regulatory Reference: FINRA Rule 3110, FINRA RN 24-09, SEC Rule 17a-4, GLBA 501(b) Safeguards Rule, NY DFS 23 NYCRR 500.11(a) (vendor / third-party network access), OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12), Federal Reserve SR 26-2 (formerly SR 11-7), FFIEC IT Examination Handbook (Information Security — Network Security), NIST SP 800-53 Rev. 5 SC-7 (Boundary Protection), SC-7(11) (Restrict Incoming Communications), SC-7(21) (Isolation of Information System Components), AC-4 (Information Flow Enforcement)
Last UI Verified: May 2026
Governance Levels: Baseline / Recommended / Regulated

Objective

Establish network-layer boundary protection for Power Platform, Microsoft Copilot Studio, Microsoft 365 Copilot–dependent integrations, and Azure-hosted AI services so that agent traffic to data sources, secret stores, AI model endpoints, and telemetry sinks is constrained to trusted, named network paths. The control combines IP firewall, IP-address-based cookie binding, virtual network (VNet) integration via subnet delegation, Azure Private Link / Private Endpoints for the resources agents call (Key Vault, Application Insights, Azure SQL, Storage, Azure OpenAI, Azure AI Search, Cognitive Services), Tenant Restrictions v2 for outbound cross-tenant access, and NSG / Azure Firewall / Private DNS for traffic inspection and name resolution.

Together these reduce the public attack surface, support segregation of customer data flows, produce reviewable network evidence for supervisory and audit obligations, and limit the population of paths an adversary or compromised agent could use for data exfiltration.

This control is adjacent and complementary to identity (Control 1.11), DLP (Control 1.5), and encryption (Control 1.15). Network isolation does not replace any of those layers — examiners assess them as a stack.

Why This Matters for FSI

  • FINRA Rule 3110 (Supervision): Restricting agent network egress to known, named network paths supports the firm's supervisory system by making agent activity reviewable from network logs and reducing the population of unmanaged data exfiltration paths a supervisor would otherwise have to evaluate. Network-flow evidence is a frequent supervisory artifact.
  • FINRA RN 24-09 / Rule 3110 (AI guidance, June 2024): Calls out cybersecurity controls specific to AI tools, including limiting where AI systems can send and receive data, controlling integration with third-party model providers, and producing testable evidence of those constraints. IP firewall, VNet integration, Private Endpoints to Azure OpenAI / Azure AI Search, and Tenant Restrictions v2 directly address that expectation by removing AI-driven lateral movement and cross-tenant data-mixing paths.
  • SEC Rule 17a-4 (Recordkeeping): When required electronic records and the systems that produce them traverse private network paths, the integrity of recordkeeping flows is easier to demonstrate and the population of network-borne tampering vectors is reduced. Private Endpoints from compute that produces or moves records support the recordkeeping system's integrity claim.
  • GLBA 501(b) Safeguards Rule (16 CFR 314.4): Network boundary protection is a recognized administrative and technical safeguard for nonpublic personal information; private connectivity to Key Vault, Storage, Azure SQL, and AI services helps support the Safeguards Rule's requirements for protecting customer information from unauthorized network access.
  • NY DFS 23 NYCRR 500.11(a) (Third-Party Service Provider Security Policy): Where Copilot Studio agents call third-party APIs, custom connectors, or external model endpoints, the firm's policy must address the security of those connections; named-network constraints, Tenant Restrictions v2, and Private Link to Microsoft-hosted dependencies provide the configuration evidence that supports the written policy.
  • OCC Bulletin 2026-13 (formerly OCC Bulletin 2011-12) / Federal Reserve SR 26-2 (formerly SR 11-7) (Model Risk Management): Documenting and constraining the network paths a model can use is part of validating the data feeds and operational environment of the model. Private endpoints, NSG flow logs, and Azure Firewall logs support that documentation. Examiners increasingly request the network architecture diagram alongside model documentation.
  • FFIEC IT Examination Handbook — Information Security (Network Security): Lists segmentation, restricted egress, and inspection of traffic between trust zones as baseline expectations for institution-controlled environments hosting sensitive data.
  • NIST SP 800-53 Rev. 5 SC-7 (Boundary Protection): Implements managed interfaces at external boundaries and key internal boundaries through IP firewall and Private Link. SC-7(11) is supported by allowlist-based ingress; SC-7(21) is supported by VNet isolation of agent compute and dependencies; AC-4 (information flow enforcement) is supported by NSG rules, Azure Firewall application rules, and Private DNS.

Important caveat. Network isolation is one layer of defense. It does not replace identity, conditional access (Control 1.11), DLP (Pillar 1), encryption (Control 1.15), or audit logging (Control 1.7). Effectiveness depends on accurate IP allowlists, sound DNS configuration, disciplined change management, and recurring verification that "public network access" remains disabled on every in-scope dependency.

No Companion Automation Solution

No companion automation solution is currently published for this control. Use the PowerShell setup playbook for orchestration patterns, and see the Solutions Index for the broader catalog. Network architecture changes have a high blast radius and are intentionally treated as a documented manual / IaC operation rather than an opinionated turnkey solution.

Control Description

The control is layered. As with encryption (Control 1.15), it is important to distinguish what Microsoft 365 / Power Platform provides by default from what requires explicit customer network configuration — examiners frequently probe this distinction, and FINRA RN 24-09 specifically calls out the AI-tooling subset.

Layer 1 — Microsoft defaults (no configuration required, applies to all tenants and zones):

  • Microsoft 365 service endpoints are TLS 1.2+ only and reachable only over the public internet to documented service URLs. Service-to-service traffic between Microsoft workloads (Exchange, SharePoint, Teams, Copilot, Graph) is encrypted in transit and does not leave the Microsoft backbone.
  • Power Platform services authenticate every request (Entra ID) and enforce tenant isolation at the application layer; cross-tenant access requires explicit B2B consent or service-principal trust.
  • Microsoft 365 Copilot prompts, grounding data, and responses inherit the network reachability of the underlying workload (Exchange, SharePoint, OneDrive, Teams, Loop, Graph). Copilot does not introduce a separate publicly addressable storage endpoint.

Layer 2 — Customer-configured network controls (required for Zone 2 / Zone 3):

  1. IP Firewall (Power Platform Managed Environments) — Restricts Dataverse and Power Platform service access to allowlisted IPv4/IPv6 ranges (up to 200 ranges, 4,000-character limit on the address field). Available on Managed Environments. Two modes: Audit only (logs blocked attempts without blocking) and Enforce (blocks).
  2. IP-Address-Based Cookie Binding — When enabled in a Managed Environment, Dataverse session cookies are cryptographically bound to the originating client IP. A stolen or replayed cookie used from a different IP is rejected, mitigating session-hijack and AitM-replay attacks. Reverse-proxy headers (X-Forwarded-For) can be configured for environments that terminate TLS at a corporate proxy.
  3. Virtual Network (VNet) Integration via Subnet Delegation — A Managed Environment is associated with one or more Azure subnets delegated to Microsoft.PowerPlatform/enterprisePolicies. Outbound calls from Dataverse plug-ins, custom connectors, Power Automate flows, and Copilot Studio agents are injected into the customer's VNet. Subnets must reside in the Azure region paired with the Power Platform region (primary and failover) and be appropriately sized — Microsoft guidance for production is at least a /24 per region to absorb scale-out.
  4. Azure Private Link / Private Endpoints for Microsoft-hosted dependencies — Each in-scope Azure resource is exposed only through one or more Private Endpoint NICs on the customer VNet, and public network access is disabled on the resource. In-scope resources for an FSI agent estate include:
    • Azure Key Vault (Customer Key root, agent secrets, certificates) — Private Link supported; combine with the Key Vault firewall.
    • Azure Storage (agent-knowledge blobs, exports, evidence) — Private Endpoint per service (blob / file / queue / table).
    • Azure SQL Database / Managed Instance (relational grounding) — Private Endpoint plus disabled public endpoint.
    • Application Insights / Log Analytics — Reached via an Azure Monitor Private Link Scope (AMPLS); the AMPLS is the Private Endpoint resource.
    • Azure OpenAI Service — Private Endpoint to the resource; required for Zone 3 agents that call Azure OpenAI from VNet-integrated compute, and for any agent processing NPI / PII / MNPI through model APIs.
    • Azure AI Search (formerly Cognitive Search) — Private Endpoint; combine with shared-private-link to reach customer data sources from the indexer over the VNet.
    • Azure AI services / Cognitive Services (Document Intelligence, Speech, Vision, Translator, Content Safety) — Private Endpoint per account; each maps to a separate privatelink.cognitiveservices.azure.com (or service-specific) DNS zone.
    • Service Bus / Event Hubs / Event Grid — Private Endpoint where async messaging is part of the agent flow.
  5. Service Endpoints vs Private Endpoints — choose deliberately. Service Endpoints extend the VNet identity to the public Azure service endpoint and remove the need for the resource to allow the broader internet, but the resource still has a public IP. Private Endpoints assign the resource a private IP on your VNet and let you fully disable public network access. For Zone 3 and any AI workload touching regulated data, use Private Endpoints; Service Endpoints are acceptable only for transitional Zone 2 designs where Private Endpoint is not yet available for the resource.
  6. Private DNS — Azure Private DNS zones are linked to the VNet so that PaaS FQDNs (e.g., *.vault.azure.net, *.database.windows.net, *.openai.azure.com, *.search.windows.net, *.cognitiveservices.azure.com) resolve to private IPs on the VNet and not to public endpoints. DNS is the single most common failure mode for Private Endpoint deployments — every Private Endpoint requires a corresponding Private DNS zone link, and on-prem clients reaching the VNet via ExpressRoute / VPN require either DNS forwarders or Azure DNS Private Resolver.
  7. VNet integration for surrounding compute — Logic Apps (Standard SKU), Azure Functions (Premium / Dedicated), App Service (Premium / Isolated), and Container Apps used as agent extensions or webhook handlers should use regional VNet integration so their outbound traffic to Microsoft-hosted dependencies traverses Private Endpoints, not the public internet. Combine with Service Endpoints / Private Endpoints on the destination for end-to-end private connectivity.
  8. Network Security Groups (NSGs) and Application Security Groups (ASGs) — NSGs on the delegated subnet and on Private Endpoint subnets restrict source and destination to the agent compute and management plane only. ASGs let you express rules in terms of agent role (e.g., "agent-runtime", "agent-egress-proxy") rather than IP literals; this scales better as the estate grows.
  9. Azure Firewall (or third-party NVA) + DNS forwarding — For Zone 3, a hub VNet hosts Azure Firewall (or an equivalent NGFW NVA) that inspects egress, enforces FQDN allowlists for any internet-bound dependency that does not yet support Private Link, and forwards DNS via the Azure Firewall DNS Proxy or Azure DNS Private Resolver. This is also where outbound calls to Microsoft 365 service endpoints that cannot be Private-Linked are inspected and logged.
  10. Tenant Restrictions v2 + Conditional Access for cross-tenant egress — On managed devices and any agent compute reaching Microsoft 365 / Entra ID endpoints, Tenant Restrictions v2 signals (combined with Conditional Access "External Tenants" controls) prevent users (and agent service accounts) from authenticating into unmanaged third-party tenants. This addresses the FINRA RN 24-09 expectation that AI-tool data flows do not leak into tenants the firm does not control. The companion control is Cross-tenant access settings in Entra (Control 1.11 reconciliation).
  11. NSG flow logs / Azure Network Watcher / Traffic Analytics — Enabled on every in-scope subnet and stored centrally (Storage + Log Analytics) for the supervisory retention period. Flow logs are the primary evidence artifact for "agent traffic stayed inside the named paths."

Together, these mechanisms remove agent traffic from the public internet for the in-scope resources, produce auditable network configuration that can be presented during examinations, and reduce the population of exfiltration paths an adversary or compromised agent could use.

Disabling public network access is operationally irreversible without a tested rollback

Toggling public network access = Disabled on Key Vault, Azure SQL, Storage, Azure OpenAI, Azure AI Search, or Cognitive Services will immediately sever any client that is not on the VNet (or in a configured exception list). This includes deployment pipelines, on-prem admin workstations, monitoring agents, and partner integrations. Validate every consumer has a private path before flipping the switch, stage the change in a non-production environment, schedule it inside an approved change window, and pre-stage the rollback (re-enable public access + selected-network rules) in the runbook. Treat this as a tested change management operation, not a "tighten the screw" reflex — restoring service after an unplanned outage of Key Vault or Azure SQL during market hours is a reportable event for many FSI firms.

Key Configuration Points

  • Power Platform environment is a Managed Environment (prerequisite for IP firewall, cookie binding, and VNet support).
  • IP Firewall configured under PPAC → Environment → Settings → Privacy + Security → IP firewall with corporate egress CIDRs (proxy / VPN egress IPs, not user RFC1918 ranges unless they actually egress directly).
  • IP Firewall mode set to Audit only during rollout, then switched to Enforce after at least one full business cycle of audit review and a documented allowlist signoff.
  • IP-address-based cookie binding enabled under the same blade; reverse-proxy IPs and forwarded-for headers configured if applicable.
  • Azure VNet provisioned in the Azure region paired to the Power Platform region (and the failover region) with a subnet delegated to Microsoft.PowerPlatform/enterprisePolicies (recommended /24).
  • Power Platform enterprise policy (network policy) created and linked to the environment via New-SubnetInjectionEnterprisePolicy (from the Microsoft.PowerPlatform.EnterprisePolicies module) for policy creation and Enable-SubnetInjection for linking to the environment. Verify current cmdlet surface against the MS Learn VNet setup guide before running.
  • Private Endpoints created for Key Vault, Storage, Azure SQL, Azure OpenAI, Azure AI Search, Cognitive Services, and any other dependency the agent calls; public network access disabled on those resources, with a staged change record per the danger admonition above.
  • AMPLS created and linked to the VNet for Application Insights / Log Analytics private telemetry; AMPLS access mode set to Private Only for Zone 3.
  • Private DNS zones linked to the VNet for every Private Endpoint:
    • privatelink.vaultcore.azure.net (Key Vault)
    • privatelink.database.windows.net (Azure SQL)
    • privatelink.blob.core.windows.net / .file. / .queue. / .table. (Storage)
    • privatelink.monitor.azure.com, privatelink.oms.opinsights.azure.com, privatelink.ods.opinsights.azure.com, privatelink.agentsvc.azure-automation.net (AMPLS)
    • privatelink.openai.azure.com (Azure OpenAI)
    • privatelink.search.windows.net (Azure AI Search)
    • privatelink.cognitiveservices.azure.com (Cognitive Services)
  • For hybrid name resolution, Azure DNS Private Resolver (or paired DNS forwarders) configured so on-prem clients and ExpressRoute consumers resolve privatelink.* zones to VNet IPs.
  • Surrounding compute (Logic Apps Standard, Functions Premium, App Service Premium / Isolated, Container Apps used as agent extensions or webhook handlers) configured with regional VNet integration into the agent VNet (or into a peered spoke).
  • NSGs on the delegated subnet and on each Private Endpoint subnet restrict source/destination to the agent runtime ASG and management plane; default-deny baseline with explicit allow rules.
  • Azure Firewall (or NGFW NVA) in a hub VNet inspects egress; FQDN application rules allow only the Microsoft 365 / partner FQDNs documented in the agent network design; DNS Proxy enabled on the firewall.
  • Tenant Restrictions v2 signals injected on managed devices (via Intune compliance / Defender for Endpoint or proxy header injection) and Conditional Access cross-tenant-access policies aligned (Control 1.11).
  • NSG flow logs v2 enabled on every in-scope subnet, sent to a Storage account + Log Analytics workspace (Traffic Analytics enabled). Retention aligned with the supervisory record requirement (Control 1.9).
  • Network change-control documented in the change record, including a network architecture diagram that names the agents, the delegated subnet, the Private Endpoints, the Azure Firewall hub, the on-prem connectivity (ExpressRoute / VPN), and the data sources reached. Diagram refreshed at least quarterly for Zone 3.

Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal Productivity) IP firewall and VNet not required. Default tenant boundary applies. Document this explicitly in the zone profile. Tenant Restrictions v2 signals recommended on managed devices to prevent cross-tenant authentication leakage from personal-productivity flows. Personal-productivity agents should not access regulated nonpublic data; cost and complexity of VNet are unjustified, and DNS / Private Endpoint mistakes at this tier produce more risk than they remove. Compensating controls live in identity (Conditional Access — Control 1.11) and DLP (Control 1.5).
Zone 2 (Team Collaboration) IP firewall enabled (Enforce) with documented allowlists. Cookie binding enabled (with proxy header config if applicable). VNet integration recommended when team agents call Azure-hosted dependencies (Key Vault, Storage, Azure SQL, Azure OpenAI). Private Endpoints required for any dependency holding customer or regulated data, with public network access disabled on those resources. Tenant Restrictions v2 enabled on managed devices and reconciled with Conditional Access cross-tenant-access settings. NSG flow logs enabled. Team agents commonly aggregate departmental data; restricting the network surface limits blast radius from credential or session compromise and supports FINRA 3110 supervision evidence. Zone 2 is also the tier where most agents start to integrate with Azure AI services, which makes Private Endpoints non-optional from a regulatory-evidence standpoint.
Zone 3 (Enterprise Managed) Full VNet integration mandatory with delegated subnets in primary and failover Azure regions. Public network access disabled on all dependent resources (Key Vault, Storage, Azure SQL, Application Insights via AMPLS Private-Only mode, Azure OpenAI, Azure AI Search, Cognitive Services, Service Bus / Event Hubs / Event Grid in scope). Private Endpoints required for every in-scope dependency. Azure Firewall (or equivalent NGFW NVA) in a hub VNet inspects all egress with FQDN application rules and DNS Proxy. Azure DNS Private Resolver for hybrid name resolution. NSG flow logs v2 + Traffic Analytics enabled. Tenant Restrictions v2 enforced on every managed device that interacts with the agent estate. IP firewall Enforce mode with reverse-proxy header validation. Quarterly attestation of network configuration with a refreshed diagram, signed by Power Platform Admin + Entra Security Admin + Compliance Officer. Annual tabletop exercise of the rollback runbook for "public network access disabled" toggles. Customer-facing agents handling NPI / PII / MNPI require defense in depth: VNet plus Private Link plus DNS hygiene plus egress inspection plus flow logging plus cross-tenant restrictions plus rehearsed rollback produce the network evidence regulators expect under Fed SR 26-2 (formerly SR 11-7), OCC Bulletin 2026-13 (formerly OCC 2011-12), NY DFS 500.11(a), and FFIEC. They also align with the AI-specific cybersecurity expectations in FINRA RN 24-09 / Rule 3110, which calls out Azure OpenAI / model-endpoint connectivity as an examiner focus area.

Roles & Responsibilities

Role Responsibility
Power Platform Admin Configures IP firewall and cookie binding in PPAC; links the environment to the Power Platform enterprise (network) policy; coordinates Managed Environment posture with the Azure platform team.
Entra Security Admin Reviews network architecture and reconciles IP firewall allowlists with Conditional Access named locations and cross-tenant-access settings (Control 1.11). Approves changes prior to Enforce. Owns Tenant Restrictions v2 policy alignment.
AI Administrator Maintains the inventory of Copilot Studio agents and Azure AI service consumers affected by network changes; ensures Zone 2/3 agents are deployed only into network-isolated environments; reviews AI-service Private Endpoint coverage during agent onboarding.
Compliance Officer Approves the network architecture against the firm's regulatory mapping (FINRA RN 24-09, NY DFS 500.11(a), GLBA 501(b)); records evidence in the supervisory file; signs the quarterly Zone 3 attestation.
Records Officer Confirms NSG flow log and Azure Firewall log retention meets the supervisory record requirement (Control 1.9).

Azure VNet, subnet, Private Endpoint, AMPLS, NSG, Azure Firewall, DNS Private Resolver, and Private DNS configuration is performed by the Azure platform team (typically holding Network Contributor and resource-specific contributor roles). That team is not a directory role in the canonical role catalog but is the operational owner of the Azure-side artifacts referenced above. Change requests crossing the Power Platform / Azure platform boundary should ride a single change record so the agent owner can see end-to-end network impact.

Control Relationship
2.1 - Managed Environments Prerequisite — IP firewall, cookie binding, and VNet support require a Managed Environment.
1.15 - Encryption (in transit and at rest) Network isolation plus encryption produces defense in depth; Private Endpoints do not remove the need for TLS, customer-managed keys, or DKE for MNPI.
1.7 - Comprehensive Audit Logging NSG flow logs v2, Traffic Analytics, Azure Firewall logs, and Private Link diagnostic logs supplement Purview audit for network-layer evidence.
1.11 - Conditional Access and Phishing-Resistant MFA IP firewall allowlists should reconcile with Conditional Access named locations; Tenant Restrictions v2 is a paired identity / network control.
1.6 - Microsoft Purview DSPM for AI Private Endpoints constrain where DSPM-monitored agent data can flow; combined with sensitivity labels, the two controls deliver flow-aware data protection.
1.5 - DLP and Sensitivity Labels DLP enforces what leaves; this control enforces where it can go. The two are complementary — DLP without network isolation leaves examiner-relevant gaps in Zone 3.
Windows 365 for Agents reference Cloud PC agent pools introduce Intune-managed execution endpoints whose network paths should be scoped against private connectivity and diagnostic evidence.

Implementation Playbooks

Step-by-Step Implementation

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

  • Portal Walkthrough — Step-by-step PPAC + Azure Portal configuration
  • PowerShell Setup — Az + Power Apps Administration scripts
  • Verification & Testing — Test cases, evidence collection, and attestation template
  • Troubleshooting — Common failures and remediation patterns (DNS, Private Endpoint NIC IP exhaustion, Azure Firewall FQDN drift, ExpressRoute hybrid resolution)

Verification Criteria

Confirm control effectiveness by verifying:

  1. IP firewall Enforce mode rejects connections from a non-allowlisted IP for an in-scope environment, returning HTTP 403 with IPFirewallBlockedRequest (or the equivalent error visible in the Dataverse Web API response). Capture the test response as evidence.
  2. Cookie binding rejects a session cookie replayed from a different client IP (verified in a controlled test against a non-production environment); reverse-proxy header configuration confirmed if a proxy is in path.
  3. Subnet delegation is present on the configured subnet (Microsoft.PowerPlatform/enterprisePolicies) and the enterprise policy is linked to the Managed Environment (visible in PPAC and via PowerShell — Get-AdminPowerAppEnvironment returns the linked policy ID).
  4. Private DNS within the VNet resolves dependency FQDNs to private IPs (e.g., Resolve-DnsName myvault.vault.azure.net from a VNet-joined VM returns a 10.x.x.x address; not the public Azure IP). Repeat for Azure OpenAI, Azure AI Search, and Cognitive Services FQDNs.
  5. Public network access is disabled on Key Vault, Storage, Azure SQL, AMPLS-scoped Application Insights / Log Analytics workspaces, Azure OpenAI, Azure AI Search, and Cognitive Services accounts in scope. Verify via portal and via az resource show --query 'properties.publicNetworkAccess' for each.
  6. AMPLS access mode is Private Only for Zone 3 workspaces (not "Open"); the AMPLS resource shows the in-scope workspaces and components.
  7. Diagnostic evidence — NSG flow logs v2 / Traffic Analytics show agent egress traversing the delegated subnet and Private Endpoints; Key Vault diagnostic logs show requests originating from the Private Endpoint NIC IP; Azure Firewall logs show no unexpected denied egress for in-scope agents.
  8. Tenant Restrictions v2 signals are present on a sample managed device (header inspection on a captured request to login.microsoftonline.com) and Conditional Access cross-tenant-access settings align with the firm's policy.
  9. Surrounding compute (Logic Apps Standard, Functions Premium, App Service Premium / Isolated, Container Apps) shows regional VNet integration enabled and outbound traffic resolving Microsoft-hosted dependencies via Private Endpoints (verified by reviewing the compute's outbound IP and DNS resolution logs).
  10. Hybrid resolution — From an on-prem client reaching the VNet via ExpressRoute / VPN, Resolve-DnsName for in-scope privatelink.* FQDNs returns the VNet private IPs (validates DNS Private Resolver / forwarder configuration).
  11. Change record for the environment includes a current network architecture diagram and a reviewer sign-off within the last quarter (Zone 3) or six months (Zone 2). The diagram names the agents, the delegated subnet, every Private Endpoint, the Azure Firewall hub, the cross-tenant restriction posture, and the on-prem connectivity.
  12. Rollback rehearsal (Zone 3) — Annual tabletop exercise documented for the "re-enable public network access" path on Key Vault and Azure SQL, with the runbook referenced in the change record.

Additional Resources

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