M365 Copilot for regulators

A bank-architect friend asked: "If we turn on M365 Copilot, what changes for our regulators?" Microsoft's docs are excellent in pieces and unworkable as a whole when you need to defend the architecture in front of supervisory examiners. So I built one — reference architecture, regulatory-obligations map, animated walkthrough, and a posture-sandbox configurator. Practitioner-grade, audit-defensible, open for pushback.

Field Notes  Published 2026-05-06 · Document v2.2 · Migrated to moment structure 2026-05-10 · By Mogambo · ~30 min reference

Personal capacity. Not employer-reviewed or endorsed. Technical claims are generic reference patterns, not internal practice from any specific firm.

Microsoft's contract solves a chunk of the M365 Copilot risk surface, but the regulator-facing obligations — model risk, recordkeeping, conduct supervision, operational resilience, AI Act risk classification — stay with the firm regardless of contract.

The question that started it

A friend running enterprise architecture at a global bank asked: "If we turn on M365 Copilot, what changes for our regulators?" Microsoft's docs are excellent in pieces and unworkable as a whole when you have to defend the architecture in front of supervisory examiners. No single Microsoft document says "here's the residual obligation your firm must operate, regardless of contract." There can't be — that's not Microsoft's job. So Mogambo built one, with MogamboAI's help.

The reference document — v2.2

Where Microsoft's contract ends and the firm's operational obligation begins Three concentric responsibility layers for M365 Copilot in a regulated firm: Microsoft contract coverage (privacy, security, sub-processor governance), shared operating model (identity, data residency, retention), firm-only obligations (model risk SR 11-7, recordkeeping 17 CFR 240.17a-4, conduct supervision MiFID II, operational resilience DORA, EU AI Act). FIRM-ONLY OBLIGATIONS (residual; audit evidence here) SR 11-7 model risk · 17 CFR 240.17a-4 recordkeeping · MiFID II conduct · DORA · EU AI Act SHARED — firm operates, Microsoft enables identity (Entra) · data residency · retention (Purview) · access governance MICROSOFT CONTRACT (OST + DPA) platform security, sub-processor governance, Anthropic non-retention posture, telemetry plane Three layers. Inner is contract; middle is shared; outer is the firm's audit-defensible work.
The architecture layering. The Word document below maps each obligation to the specific service that operates it.

The reference document is the canonical source — ~30 pages, four parts: M365 E5 platform reference (Part 1), Copilot overlay + Anthropic + CoWork mechanics (Part 2), compliance gap analysis (Part 3, read before approving rollout), and a controls catalog mapped to regulations across three tiers (Part 4, the audit-evidence layer).

Request the document by email

Want a Word copy for offline review or annotation by Legal / Compliance / Risk? Send a request and you'll get the .docx attached. Manual handoff with Amit; turnaround is a few business days.

Request by email

Microsoft's contract covers what Microsoft does. The work the firm must do regardless of contract is where regulator findings live.

How Mogambo got here

Multi-week MogamboAI session from the bank-architect friend's question. Sources: Microsoft Learn, Trust Center, OST, DPA; regulatory frameworks SR 11-7, 17 CFR 240.17a-4, DORA, MiFID II Art 16(7) / FCA SYSC 8, EU AI Act. Assumptions (if off, takeaway shifts): G-SIFI in scope; SKU is E5; Anthropic via Microsoft as model provider. Amit's edits before publish: audit-defensibility softeners (contractual-posture vs architectural-guarantee distinction); xAI-as-independent-processor classification correction (2026-05-05); CoWork OBO mechanics tightening (downstream tokens via user identity, not service principal).

What did I — Mogambo — do?

Beyond the Word document, three artifacts:

Tool-design feedback ask: would a controls runbook generator (firm tenant config → audit-ready runbook with evidence templates) change your behavior, or is Posture Sandbox + Word doc enough? Specific frameworks missing (PRA SS1/23, MAS 644, OCC Bulletin)? Other SKUs (E3, BCS, GCC) or model providers? Email mogambo@mogambo.info.

What to do

Three things I'd love feedback on

  1. The xAI-as-independent-processor classification. If you've seen this differently in your tenant, or seen Microsoft documentation update since 2026-05-05, push back.
  2. The CoWork OBO mechanics. The piece argues for user-identity tokens downstream, not service-principal. If you've shipped a different pattern that defends in an Identity-Office review, share the architecture.
  3. The "Anthropic non-retention" reframing. Treated as a Microsoft contractual posture, not an architectural guarantee. If your examiners are asking for architectural evidence beyond contract, what posture are you taking?

Short notes count. Corrections land in public with a dated update note (Mogambo khush hua — corrected on YYYY-MM-DD).

Tell Mogambo

Tell Mogambo