Skip to content

Control 1.15: Encryption: Data in Transit and at Rest

Control ID: 1.15
Pillar: Security
Regulatory Reference: GLBA 501(b) Safeguards Rule, SEC Regulation S-P 17 CFR 248.30, NY DFS 23 NYCRR 500.15(a)–(b), FFIEC IT Examination Handbook (Information Security), SOX 404, FINRA 4511, FINRA 25-07, SEC 17a-4(f), PCI DSS 4.0 §3 & §4, NIST SP 800-53 SC-8 / SC-12 / SC-13 / SC-28
Last UI Verified: April 2026
Governance Levels: Baseline / Recommended / Regulated

Objective

Confirm that all data processed by Copilot Studio agents and Microsoft 365 Copilot is protected with TLS 1.2+ in transit and AES-256 (or stronger) at rest, layer customer-managed keys (Microsoft Purview Customer Key) and Double Key Encryption (DKE) where required, and document key custody, rotation, and revocation procedures aligned to financial-services regulatory expectations.

This control is foundational — it underpins every other Pillar 1 confidentiality control (DLP, IRM, audit log integrity, Zone 3 isolation).

Why This Matters for FSI

  • GLBA 501(b) Safeguards Rule (16 CFR 314.4(c)(3)): Requires encryption of customer non-public information (NPI) both in transit over external networks and at rest. Microsoft 365 default service encryption helps meet the at-rest baseline; Customer Key is recommended where the customer must demonstrate exclusive cryptographic custody.
  • SEC Regulation S-P, 17 CFR 248.30(a): Broker-dealers and investment advisers must adopt written policies addressing administrative, technical, and physical safeguards for customer records — encryption configuration evidence supports the technical-safeguard prong.
  • NY DFS 23 NYCRR 500.15(a)–(b): Covered entities must encrypt NPI in transit over external networks and at rest; where encryption at rest is infeasible, the CISO must approve effective alternative compensating controls and review the determination at least annually.
  • FFIEC IT Examination Handbook — Information Security Booklet: Lists encryption of sensitive data in transit and at rest as a baseline expectation; examiners look for documented key-management procedures, segregation of duties around keys, and evidence of cryptographic-control testing.
  • SEC 17a-4(f) / FINRA 4511 / FINRA 25-07: Encryption supports the confidentiality of retained books and records (including AI agent prompts, responses, and decision logs called out by FINRA 25-07). WORM-format retention is addressed in Control 1.9.
  • SOX 404: Customer-managed keys with documented dual-control rotation provide an internal control over the integrity of financial-reporting records.
  • PCI DSS 4.0 Requirements 3 and 4: Strong cryptography (AES-256, TLS 1.2+) is required for stored and transmitted account data; applies if Copilot Studio agents touch cardholder data flows.
  • OCC 2011-12 / Fed SR 11-7 (Model Risk): Encryption of model inputs, outputs, and decision logs supports the integrity element of model-risk management.
  • NIST SP 800-53 Rev. 5 — SC-8 (transmission), SC-12 (key establishment), SC-13 (cryptographic protection), SC-28 (data at rest): Maps directly to the configuration evidence collected for this control.

No companion solution by design

Not all controls have a companion solution in FSI-AgentGov-Solutions; solution mapping is selective by design. This control is operated via native Microsoft admin surfaces and verified by the framework's assessment-engine collectors. See the Solutions Index for the catalog and coverage scope.

Control Description

The control is layered. It is important to distinguish what Microsoft 365 provides by default from what requires explicit customer configuration — examiners frequently probe this distinction.

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

  • In transit: TLS 1.2+ is enforced by Microsoft 365 service endpoints; TLS 1.0 and 1.1 client connections are blocked at the service. Service-to-service traffic (e.g., Exchange to SharePoint, Copilot to Graph) is encrypted with TLS.
  • At rest (volume): BitLocker AES-256 encrypts every disk in every Microsoft 365 datacenter.
  • At rest (service): Microsoft 365 service encryption with Microsoft-managed keys wraps individual mailboxes, SharePoint files, OneDrive files, and Teams chat content above the BitLocker layer.
  • Copilot interactions: Microsoft 365 Copilot prompts, grounding data, and responses inherit encryption from the underlying workloads (Exchange, SharePoint, OneDrive, Teams, Loop). They are not separately persisted in plaintext.

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

  1. TLS posture audit — Verify no on-prem hybrid component, custom connector, or BYO endpoint reintroduces TLS 1.0/1.1; certificate inventory and expiry tracking.
  2. Microsoft Purview Customer Key (BYOK) — Customer-supplied root keys hosted in Azure Key Vault wrap the Microsoft service encryption keys for Exchange Online, SharePoint Online, OneDrive for Business, and Teams files. Requires two Azure Key Vaults in different Azure regions with two RSA keys (Standard SKU minimum; Premium HSM-backed recommended; Managed HSM available for the highest assurance).
  3. Power Platform Customer-Managed Key (CMK) — Per-environment CMK for Dataverse-backed Copilot Studio environments. Requires the environment to be a Managed Environment and the Key Vault to be in the same Azure region as the environment.
  4. Data Encryption Policies (DEPs) — Created in Microsoft Purview and assigned to mailboxes and SharePoint sites that hold agent knowledge sources or grounding data.
  5. Double Key Encryption (DKE) — Customer-hosted DKE key service paired with a Purview sensitivity label whose encryption setting is "Double Key Encryption". Files protected by a DKE label cannot be decrypted by Microsoft, by Copilot, or by any service that does not have access to the customer key endpoint. Recommended for material non-public information (MNPI), M&A working files, and other holdings that must be cryptographically isolated from Microsoft cloud services.
  6. Key custody and rotation — Documented rotation cadence (Zone 1 inherited from Microsoft, Zone 2 annual, Zone 3 quarterly), dual-control approval for key creation/rotation, soft delete + purge protection enabled on every Key Vault, and a rehearsed key-revocation runbook.

Customer Key revocation is a one-way data-destruction operation

Initiating Customer Key revocation triggers an irreversible data purge path. After the purge window completes, all data encrypted under the revoked DEP becomes permanently unrecoverable — by you, by Microsoft, by anyone. This is a deliberate design control intended to support cryptographic erase scenarios (e.g., GDPR Article 17, tenant exit). It is not a routine recovery or rotation operation. Organizations must restrict revocation rights to a small named group, gate the action behind a documented break-glass procedure with explicit CISO and Records Officer sign-off, and verify a rehearsal in a non-production tenant before relying on the path. The same warning applies to DKE: deleting or losing the customer DKE key renders all DKE-protected files permanently unreadable.

Key Configuration Points

  • TLS posture: Test every public-facing tenant endpoint (e.g., tenant.sharepoint.com, custom domains, hybrid Exchange) with SSL Labs (Qualys) or Test-NetConnection/openssl for TLS 1.2+ only, no SSLv3/TLS 1.0/TLS 1.1, no RC4/3DES, valid certificate chain.
  • Azure Key Vault provisioning for Customer Key: Two vaults in two Azure regions (paired-region recommended). Soft delete enabled (default, cannot be disabled), purge protection enabled (irreversible — required for Customer Key), retention 90+ days. Premium SKU with HSM-backed RSA keys for Zone 3.
  • DEP service principal access: Grant the Microsoft 365 DEP service principal (Office 365 Exchange Online / Office 365 SharePoint Online) the wrapKey, unwrapKey, and get permissions on each Key Vault key (vault access policy or Azure RBAC Key Vault Crypto Service Encryption User role).
  • Customer Key activation: Create separate DEPs for Exchange Online (multi-workload) and SharePoint/OneDrive workloads via New-M365DataAtRestEncryptionPolicy and New-DataEncryptionPolicy; assign to mailboxes (Set-Mailbox -DataEncryptionPolicy) or tenant (Register-SPODataEncryptionPolicy).
  • Power Platform CMK: Requires Managed Environment, Azure Key Vault in the same region as the Dataverse environment, and the Dataverse service principal granted Key Vault key permissions before enabling CMK in PPAC.
  • DKE key service: Customer-hosted REST endpoint (sample .NET implementation provided by Microsoft) deployed for high availability, fronted by HTTPS with a publicly trusted certificate, registered in a Purview sensitivity label whose encryption type is "Double Key Encryption" with the URL of the customer key service.
  • Copilot interaction encryption: Microsoft 365 Copilot prompts/responses inherit DEP coverage from the underlying workload (Exchange / SharePoint / OneDrive / Teams). There is no separate "Copilot DEP" surface today — verify by mapping each Copilot grounding source to a workload covered by a DEP.
  • Certificate management: Track expiry of all customer-controlled certificates (custom domains, hybrid connectors, DKE service); alert ≥60 days before expiry.
  • Diagnostic logging: Stream Key Vault audit logs (AuditEvent category) to Microsoft Sentinel or your SIEM; alert on any KeyDelete, KeyDisable, KeyDeleted, or DEP-policy changes.
  • Key rotation: Use Key Vault key versions (not new key names) for rotation; Customer Key automatically picks up the latest enabled version on its next wrap operation.

Zone-Specific Requirements

Zone Requirement Rationale
Zone 1 (Personal) Microsoft default service encryption (BitLocker + per-workload service encryption with Microsoft-managed keys); TLS 1.2+ enforced; no customer key custody required. Zone 1 covers low-sensitivity personal-productivity agents; Microsoft defaults are aligned with GLBA / DFS baseline encryption expectations.
Zone 2 (Team) All Zone 1 +
• Microsoft Purview Customer Key activated for Exchange Online and SharePoint/OneDrive DEPs covering team data and agent grounding sources
• Two Azure Key Vaults (paired regions) with soft delete + purge protection
• Annual key rotation, dual-control approval
• Power Platform CMK on the Dataverse environment hosting team-tier Copilot Studio agents
• TLS posture audit on any custom connector / hybrid surface		 Team-scoped agents touch business records subject to FFIEC / SEC examination; customer key custody supports GLBA / DFS 500.15 evidence and SOX 404 internal-control testing.
Zone 3 (Enterprise) All Zone 2 +
• Premium Key Vault SKU with HSM-backed RSA 3072+ keys (Managed HSM acceptable for highest assurance)
• Quarterly key rotation, dual-control + Records Officer + CISO sign-off
• Double Key Encryption (DKE) sensitivity label applied to MNPI / M&A working files / privileged communications
• Documented and rehearsed Customer Key revocation runbook (test executed in non-prod tenant)
• TLS 1.3 preferred end-to-end; mTLS on enterprise integrations; certificate-pinning where supported
• Key Vault diagnostic logs streamed to Microsoft Sentinel with alerting on key disable/delete		 Zone 3 covers customer-facing and regulator-facing flows; DFS 500.15(b) compensating-control documentation, OCC 2011-12 model integrity, and DKE for MNPI cryptographic isolation drive these requirements.

Roles & Responsibilities

Role Responsibility
Entra Security Admin Primary owner. Customer Key activation, Azure Key Vault access policy / RBAC, key rotation, DKE key-service registration in sensitivity labels.
Purview Info Protection Admin Create and assign DEPs in Microsoft Purview; configure DKE sensitivity labels; publish to scoped users.
SharePoint Admin Apply registered DEPs to SharePoint Online / OneDrive agent knowledge-source sites via Register-SPODataEncryptionPolicy.
Exchange Online Admin Assign Exchange Online DEPs to mailboxes used by agents (Set-Mailbox -DataEncryptionPolicy).
Power Platform Admin Configure CMK on Managed Environments hosting Copilot Studio agents.
AI Administrator Validate that Copilot grounding sources map to DEP-covered workloads; coordinate DKE label deployment with agent-author teams.
Compliance Officer Validate key rotation evidence, attest to DFS 500.15 / GLBA encryption posture, sign off on revocation-runbook rehearsals.
Control Relationship
1.5 - DLP and Sensitivity Labels Label-based encryption
1.16 - IRM for Documents Document-level protection
1.7 - Audit Logging Encryption audit events
2.1 - Managed Environments Environment encryption

Implementation Playbooks

Step-by-Step Implementation

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

Verification Criteria

Confirm control effectiveness by verifying:

  1. TLS posture: SSL Labs (Qualys) test of each public tenant endpoint returns Grade A or A+ with TLS 1.2+ only and no weak cipher suites; results stored as evidence with date.
  2. Customer Key activation (Zone 2/3): Get-DataEncryptionPolicy and Get-M365DataAtRestEncryptionPolicy return State: Active (not PendingActivation) for all expected DEPs; PrimaryKeyVault and SecondaryKeyVault URIs both resolve.
  3. Key Vault hardening: Every Customer Key vault shows EnableSoftDelete=True, EnablePurgeProtection=True, retention ≥ 90 days; access scoped to the DEP service principal with wrapKey, unwrapKey, get only — no broader write permissions; diagnostic logs streaming to Sentinel/SIEM with confirmed events in the last 7 days.
  4. DKE (Zone 3): A Purview sensitivity label with encryption type "Double Key Encryption" exists, points to the registered customer DKE service URL, and is published to the MNPI-handling user scope; a test document labelled with it is unreadable to a control account that does not have access to the DKE key service.
  5. Power Platform CMK: PPAC environment detail page shows "Encryption key managed by customer" with the linked Key Vault key URI displayed; environment is a Managed Environment.
  6. Copilot grounding coverage: Each Copilot grounding source (mailbox, SharePoint site, Teams channel storage) is mapped to an active DEP; mapping is recorded in the encryption inventory.
  7. Key rotation evidence: Most recent rotation falls within the cadence required for the zone; rotation ticket records dual-control approval and includes the new key version URI.
  8. Revocation runbook (Zone 3): Documented runbook exists, names the approval chain, and includes a dated rehearsal report from a non-production tenant.

Additional Resources

Updated: April 2026 | Version: v1.4.0 | UI Verification Status: Current