Copilot for Financial Services: FINRA, SEC, SOX & GLBA Compliance

Microsoft 365 Copilot lands in financial services at the intersection of the densest compliance stack in the enterprise. A single bank or broker-dealer deployment is simultaneously in scope for SOC 2 Type II, SOX Section 404 ITGC, GLBA Safeguards, FINRA supervision, SEC 17a-4 retention, NYDFS 500 cybersecurity, OCC third-party risk management, and FFIEC Information Security Booklet controls. Add state privacy laws (CCPA, CDPA, CTDPA, UCPA, and more) and GDPR for any customer data with an EU nexus, and the control surface expands further.

This brief is the financial-services companion to our pillar guide on Microsoft 365 Copilot HIPAA, SOC 2, and FedRAMP governance. It focuses on the patterns specific to banks, broker-dealers, registered investment advisers, and asset managers — supervision, retention, SOX ITGC, and examiner-ready evidence.

Scoping Copilot Against the Financial Services Regulatory Stack

Begin with a scoping decision: which Copilot-touched workflows are in scope for each binding framework?

• SOX Section 404 / ITGC — Copilot outputs used in financial reporting, reconciliations, or management's representations about internal controls.
• FINRA supervision — Copilot-generated business communications (emails, client letters, research) used by registered representatives.
• SEC 17a-4 — Copilot interaction with 17a-4-covered books and records; the Copilot output itself may not be a record, but the underlying records must be retained in a 17a-4-compliant archive.
• GLBA Safeguards — Copilot access to nonpublic personal financial information (NPI).
• NYDFS 500 — Copilot deployment under the firm's cybersecurity program.
• CCPA/CDPA/state privacy — Copilot processing of personal information belonging to state residents.

Document the scope in a formal Copilot Scoping Register and update quarterly. Treat scope changes (new Copilot workloads, new departments, new integrations) as formal change-management events.

FINRA Regulatory Notice 24-09 and AI Supervision

FINRA Regulatory Notice 24-09 clarified that AI-generated business communications fall under existing supervision, retention, and suitability rules. For Copilot, this translates to practical requirements:

• Written supervisory procedures (WSPs) must address Copilot use. Update the WSPs to name Copilot, define approved use cases, and specify supervisory review expectations for Copilot-generated content.
• Retention follows the underlying record type. Copilot-drafted emails to clients are subject to the same retention as manually drafted emails. Route outputs through existing communications surveillance tools (Smarsh, Global Relay, Theta Lake).
• Suitability obligations for registered representatives are not delegable to AI. Copilot can draft research or recommendations; the representative remains accountable for the content that reaches the client.
• Attribution — FINRA has signaled that AI-generated content should be identifiable. Firms should decide whether to label Copilot-drafted communications internally and maintain attribution for supervisory review.

SEC 17a-4 and WORM Retention

SEC 17a-4 requires Write-Once-Read-Many (WORM) retention for qualifying books and records. Microsoft 365 Copilot is not a WORM archive. Two patterns solve this:

Pattern A: Retain the underlying records, not the Copilot output. When Copilot interacts with 17a-4-covered records (emails, order blotters, trade confirms), retain the underlying record in a 17a-4-compliant archive and treat Copilot as a presentation layer. This is the prevailing pattern.

Pattern B: Retain Copilot outputs in a compliant archive. When a firm decides that Copilot outputs themselves are business records (for example, Copilot-drafted research that is distributed to clients), retain them in a 17a-4 archive — Microsoft Purview with Preservation Lock, Smarsh, Global Relay, or an equivalent certified archive. Purview alone without Preservation Lock does not satisfy 17a-4.

Document the pattern chosen in the firm's recordkeeping policy and validate with external counsel and examiner expectations.

SOX ITGC for Copilot

Copilot itself is rarely a SOX-scoped system, but Copilot-generated content that feeds financial reporting or supports ITGC narrative can be in scope. A defensible SOX posture for Copilot includes:

• Named Copilot in the IT General Controls narrative as a productivity layer
• Documented that Microsoft SOC 2 Type II and SOC 1 reports cover the platform
• Change management referenced for Copilot tenant settings changes
• Evidence that any Copilot-generated financial summaries are reviewed by a named human before external use
• Pilot wave documentation demonstrating controlled rollout

External auditors will ask, at a minimum, for the Microsoft SOC 2 report, the tenant Copilot settings, the list of Copilot-licensed users in finance functions, and evidence of human review for any Copilot-drafted content reaching external reporting.

GLBA Safeguards and Customer Financial Information

The revised FTC Safeguards Rule (16 CFR 314) requires specific administrative, technical, and physical safeguards for customer information. For Copilot, the high-impact practices include:

• Named Qualified Individual accountable for the Safeguards program, with Copilot explicitly in scope
• Written risk assessment covering Copilot deployment, updated at least annually
• Access controls — Entra ID + Conditional Access + Copilot licensing discipline
• Encryption at rest and in transit
• Continuous monitoring or annual penetration testing covering the Copilot deployment
• MFA for Copilot access
• Secure disposal when users depart, including Copilot license revocation
• Change management for Copilot tenant settings
• Incident response including the 30-day Safeguards notification trigger

Map these practices against the SOC 2 and NYDFS control set to avoid duplicated effort — most of the controls overlap across frameworks.

NYDFS 500 Amendment and Copilot

The 2023 NYDFS 500 amendment introduced stricter requirements that apply directly to Copilot:

• 500.11 Third Party Risk — Copilot deployment requires formal third-party risk assessment covering Microsoft as a service provider
• 500.16 Incident Response — Copilot-related incidents must be covered in the firm's incident response plan, with the 72-hour notification obligation
• 500.17 MFA — All Copilot-licensed users require MFA enforced via Conditional Access
• 500.2 Governance — CISO or equivalent must include Copilot in the annual cybersecurity risk assessment
• 500.9 Penetration Testing — Annual testing should scope the Copilot deployment appropriately

Document the Copilot posture in the annual NYDFS filing and reference in board-level cybersecurity reporting.

Reference Architecture: Mid-Size Bank

A typical mid-size bank Copilot deployment uses five layers:

1. Identity and access — Entra ID, Conditional Access enforcing MFA and device compliance, Copilot licensing via governed security groups.
2. Content classification — Purview sensitivity labels with Confidential-NPI parent label and sub-labels for SSN, account-number, and wealth management files.
3. Copilot governance — Tenant settings restrict Copilot to licensed groups, DLP policies detect SSN / account numbers / routing numbers in Copilot outputs, acceptable-use policy signed by every licensed user.
4. Supervision and retention — Copilot-drafted communications flow through the firm's existing supervisory surveillance tool; underlying records are retained in a 17a-4-compliant archive where applicable.
5. Monitoring — Purview Copilot audit exports to Sentinel with retention matching the longest framework; analytic rules detect anomalies and first-time use in regulated functions.

Examiner-Ready Evidence Package

Bank and broker-dealer examinations touching Copilot should produce evidence quickly. Pre-build a package that includes:

• Microsoft SOC 2 Type II and SOC 1 reports (from Service Trust Portal)
• Tenant Copilot configuration snapshot
• List of Copilot-licensed users by role
• Purview sensitivity label policies and DLP policies
• Purview Copilot audit samples
• Conditional Access policies for Copilot
• Acceptable-use policy and training attestation records
• Copilot-specific incident response runbook
• Third-party risk assessment covering Microsoft and Copilot
• Change management log for Copilot tenant settings
• Annual penetration testing report scoping Copilot

Store the package template in a compliance SharePoint site and run a quarterly tabletop with internal audit.

Phased Rollout for a Mid-Size Bank

A mid-size bank Copilot deployment typically sequences across five waves:

Wave 0 — Governance foundation. BAA acceptance verified, tenant settings locked down, oversharing remediation underway, sensitivity label taxonomy published with Confidential-NPI parent label and sub-labels for SSN, account numbers, and wealth management files. Initial risk assessment drafted for GLBA Safeguards, NYDFS 500, and SOC 2.

Wave 1 — Corporate functions. 100–200 licensed users in HR, marketing, corporate communications, and IT. No NPI, no trading data, no SOX-scoped workflows. Validates licensing workflow, training attestation, DLP policies, and Sentinel analytic rules.

Wave 2 — Middle-office and back-office. 300–500 licensed users in operations, finance (non-SOX), and compliance. NPI in scope; DLP policies enforced. SOC 2 Type II audit period evidence collection begins formally.

Wave 3 — Front-office expansion. Wealth managers, commercial bankers, and client-facing teams. Communications surveillance integration validated. FINRA supervision workflow formalized.

Wave 4 — Steady state. Copilot as default productivity layer; quarterly access reviews; annual training re-attestation; continuous audit evidence collection; updates to annual NYDFS filing.

Skip Wave 0 and the bank will encounter a preventable incident in Wave 2. Skip Wave 1 and the bank will be diagnosing DLP, Sentinel, and training problems under production pressure with NPI in scope.

Board and Audit Committee Reporting

Bank boards and audit committees now ask AI-specific questions tied to NYDFS 500 and the Federal Reserve's Supervisory Letter on AI. A standard quarterly report for Copilot should include:

• Active license count by business unit
• Sensitivity label coverage on NPI-bearing sites
• Purview Copilot audit event volume trend
• DLP alert volume and disposition
• Incident count, root causes, and 500.16 notification history
• Training attestation rate and recertification pipeline
• Open POA&M items related to Copilot
• Microsoft SOC 2 Type II and SOC 1 report currency
• Third-party risk assessment status for Microsoft and adjacent vendors

Delivering this quarterly materially simplifies the annual NYDFS 500.2 filing, SOC 2 Type II evidence collection, and any examination inquiry from OCC, Fed, or state regulators.

Adjacent Vendor BAAs and Contracts

Microsoft is the primary vendor for Copilot, but a bank's Copilot deployment typically involves adjacent vendors whose contracts also matter for compliance:

• Communications surveillance (Smarsh, Global Relay, Theta Lake) processing Copilot-drafted communications
• SIEM and SOC (Sentinel, Splunk, etc.) retaining Copilot audit events
• Archive and retention (Purview with Preservation Lock, or specialty 17a-4 archive) for Copilot outputs that qualify as records
• EDR and device management for endpoints accessing Copilot
• Background check providers for personnel with Copilot access to NPI

For each, review the vendor contract, confirm applicable AI-handling language, and document the third-party risk assessment under NYDFS 500.11.

Related Reading

• Pillar: Microsoft 365 Copilot HIPAA, SOC 2, FedRAMP governance
• Copilot for healthcare: HIPAA BAA deployment guide
• Copilot for government: FedRAMP High & ITAR deployment
• Copilot safety blueprint: financial services SOX / SEC
• Conditional Access policies for Microsoft 365 Copilot
• Auditing Microsoft Copilot activity with Purview

Frequently Asked Questions

Does FINRA require retention of Copilot outputs?

FINRA Regulatory Notice 24-09 signals that AI-generated content used in business communications falls under existing supervision and retention rules. If Copilot drafts emails, research commentary, or client communications, route the outputs through the firm's communications surveillance and retention tooling (Smarsh, Global Relay, Theta Lake) the same way you would for any other communication. Retention periods follow the underlying record type.

How does SEC 17a-4 apply to Copilot?

SEC 17a-4 requires WORM retention of qualifying books and records. Copilot is not a WORM archive. If Copilot interacts with 17a-4-covered records (emails, order blotters, trade confirms), retain the underlying records in a 17a-4-compliant archive such as Microsoft Purview with Preservation Lock, Smarsh, or Global Relay. Treat Copilot as a productivity layer, not a record retention system.

What NYDFS 500 obligations apply to Copilot?

NYDFS 500.11 (third-party risk) and 500.16 (incident response) both apply. Cover Copilot in the annual 500.2 risk assessment, include Copilot incidents in the 500.16 runbook, and ensure MFA per 500.17 for all Copilot-licensed users via Conditional Access. Document the Copilot AI risk assessment under 500.11 with reference to the Microsoft BAA and Product Terms.

Can I use Copilot for investment research?

Yes, but with supervision. Treat Copilot-drafted research as any other analyst content — subject to supervisory review, conflict of interest checks, and retention. Do not allow Copilot to generate research that is published externally without human review and formal attribution. For regulated broker-dealers, route outputs through the firm's existing research supervision workflow.

How should SOX ITGC treat Copilot?

Copilot itself is rarely a SOX-scoped system, but Copilot-generated content that feeds financial reporting or ITGC narrative can be. Document Copilot in the IT General Controls narrative as a productivity layer, confirm the Microsoft SOC 2 Type II report as inherited control evidence, and ensure that any Copilot-generated financial summaries are reviewed by a named human before use in external reporting.

What about Copilot in wealth management client communications?

Copilot-drafted client communications are communications for regulatory purposes — retention, supervision, and disclosure rules all apply. Route through existing communications surveillance and archive. Train advisers that Copilot is a drafting aid, not a compliance filter. Formal attestation by the adviser before sending remains required.