Is Your Copilot Memory Examiner-Ready? Three Governance Gaps Banks and Credit Unions Must Document

Your loan officers are saving time. Copilot drafts correspondence faster, surfaces the right policy section without a ten-minute document hunt, and keeps meeting notes that would otherwise get lost. That productivity gain is real, and it is why your institution deployed Copilot in the first place.

Now your examiner asks a question you did not expect: "Where are your Copilot interaction logs, and how long do you keep them?"

If you pause before answering, you are not alone. Most financial institutions that deployed Microsoft 365 Copilot Business focused on the user-facing setup, verified that data stays inside the tenant, and moved on. The deeper question, which Microsoft Purview controls govern what Copilot stores about your staff and how long it keeps it, did not get the same attention.

This article covers the three specific governance gaps that NCUA, OCC, and FFIEC-supervised institutions need to document before that conversation happens. None of them require a compliance attorney to fix. All of them require configuration work that most institutions have not done.

Why Copilot Memory Is a Governance Question, Not Just a Product Feature

Microsoft 365 Copilot includes a feature called Copilot Memory. When Enhanced Personalization is on in your tenant, Copilot stores discrete facts about each user: their preferred response format, their role context, things they have explicitly told Copilot to remember, and things Copilot inferred from conversations. Those facts persist across sessions.

This is genuinely useful. A loan officer who does not have to re-explain their document naming convention every morning gets more out of Copilot than one who starts from scratch each session. The productivity case is straightforward.

The governance question is where it gets complicated. Saved memories are stored in each user's Exchange mailbox, inside a hidden mailbox folder used for Copilot personalization. That means they follow Exchange mailbox compliance controls, including Customer Lockbox and encryption at rest. But it also means they behave differently from Copilot conversation data in ways that most compliance officers do not realize until they go looking.

Here are the three gaps your institution needs to document.

The three Microsoft 365 Copilot governance gaps NCUA, OCC, and FFIEC-supervised institutions must document before an examiner asks.

Gap 1: Standard Purview Retention Policies Do Not Cover Copilot Memory

If your institution has applied a retention policy to the "Microsoft Copilot experiences" location in Microsoft Purview, you may assume your Copilot governance is complete. That assumption is wrong in one specific and important way.

The "Microsoft Copilot experiences" retention location covers user prompts and Copilot responses, meaning the back-and-forth conversation text. Purview stores those messages in a hidden Exchange folder used for compliance purposes, separate from the CopilotMemory folder. Your retention policy governs that conversation data correctly.

It does not govern saved memories.

Because saved memories are stored as Exchange mailbox contact items rather than as conversation messages, the Copilot retention location does not reach them. According to Microsoft's documentation on Copilot personalization memory, retention policies configured in Microsoft Purview do not apply to Copilot memory by default.

To govern memory retention, your institution would need to apply Exchange mailbox retention policies specifically targeting the hidden Copilot retention location. That is not a standard configuration. It is also not something most institutions have set up, because the gap was not visible from the Purview retention policy interface.

"We have a retention policy for Copilot" is not the same as "we have a retention policy for Copilot memory." An FFIEC IT examiner reviewing your AI governance posture will look at records retention as a baseline. Know which one you have.

Gap 2: Copilot Memory Writes Are Not in the Purview Audit Log

The Purview audit log for Copilot interactions captures a useful set of events. When a user talks to Copilot, which files were accessed during the conversation, what plugins or agents were involved, and when the interaction occurred are all logged as CopilotInteraction record types. Your compliance team can pull those records for an eDiscovery request or an examiner inquiry.

What the audit log does not capture: the act of Copilot creating, updating, or deleting a saved memory.

When Copilot infers a fact about a user and writes it to the CopilotMemory folder, that write action does not appear in the Purview audit log as a distinct auditable event. Microsoft's audit documentation lists the specific admin activities and user interaction events that are captured. Memory writes and deletes are not among them.

This matters for regulated institutions because FFIEC examiners and OCC supervisors looking at AI governance posture may increasingly expect AI systems that interact with member or customer data to generate complete audit trails for those interactions. If Copilot is building a behavioral profile of your staff members by storing inferred facts in their mailboxes, and those write operations are not audited, you have an AI activity gap in your compliance records.

This is not a hypothetical risk. A DLP bypass vulnerability that affected some Copilot configurations before Microsoft patched it in early 2026 showed that default Copilot behavior and compliant Copilot behavior are not the same thing. Default configurations give you a working product. Governed configurations give you an audit-ready one.

An NCUA examiner asking about AI audit trails may not yet know to ask specifically about Copilot memory writes. But as AI governance frameworks mature, that question will come. Document your position now while you can do it on your timeline rather than theirs.

Gap 3: Custom Instructions Are Not Discoverable by Admins

This is the one most institutions find genuinely surprising.

Copilot Chat includes a feature called Custom Instructions. Users can type in explicit behavioral preferences: preferred response length, how Copilot should address them, role context, and specific instructions for how Copilot should handle certain topics. Those instructions persist and apply to every subsequent Copilot Chat session.

Unlike saved memories, which live in the Exchange mailbox and are searchable by Purview eDiscovery tools, custom instructions are stored in a way that admins cannot access. There is no Microsoft 365 admin center path, no Purview eDiscovery query, and no Graph API endpoint that lets an administrator retrieve a user's custom instructions.

If a compliance officer at your institution wants to know what instructions an employee has given to Copilot, because those instructions may affect how Copilot handles customer-facing communications, regulatory filings, or loan documentation, there is no admin-facing way to find out. The user can export their own custom instructions manually, but that export depends on the user's cooperation.

This is not a malicious design. Custom instructions are a personalization feature, not a communication channel. But in a regulated environment where institutions need to demonstrate that AI tools are being used appropriately, the absence of any admin visibility into custom instructions is a governance gap worth acknowledging in writing.

No FFIEC examination procedure today asks specifically about Copilot custom instructions. But the underlying principle, that institutions should be able to account for how AI tools are being used within the institution's regulatory environment, is well-established. A written policy that acknowledges this limitation and describes how your institution addresses it is a defensible position. Silence is not.

Microsoft Purview coverage map: what the standard Copilot experiences retention location covers and what requires additional configuration for NCUA, OCC, and FFIEC-supervised institutions.

What Purview Does Cover (So You Know Where You Stand)

Before this article creates more anxiety than it resolves, here is what Microsoft Purview does cover correctly when configured.

The "Microsoft Copilot experiences" retention location in Purview applies to user prompts and Copilot responses across Microsoft 365 Copilot, Security Copilot, Copilot in Fabric, and Copilot Studio. Those conversation messages are stored in a hidden Exchange folder for compliance purposes. Purview eDiscovery tools can search them. Retention policies apply. When the retention period expires, messages move through SubstrateHolds before permanent deletion.

The gaps are specific. Conversation data: covered. Saved memories: not covered by default. Custom instructions: not admin-discoverable. Knowing which is which lets you document your actual posture instead of assuming your Purview setup covers everything it does not.

The Configuration ABT Runs Before Your Staff Uses Copilot

ABT manages Microsoft 365 tenants for credit unions, community banks, and mortgage companies. Before your institution deploys Copilot to staff, we run a configuration checklist that covers the items most institutions miss. If you have not yet reviewed the tenant-level settings that shape what users can personalize, our guide to Microsoft 365 Copilot Chat personalization settings for financial institutions covers those controls first.

That includes setting up Purview audit logging for Copilot interactions, which covers conversation data. It includes reviewing the Enhanced Personalization admin controls and helping you decide whether to leave them on with user education or turn them off for specific groups. It includes configuring retention policies for Copilot conversation data at the right scope, and documenting the custom instructions gap in your AI acceptable-use policy so you have a written position when the question comes up.

None of this happens automatically when you buy a Copilot Business license. It requires configuration decisions, and those decisions need to be made by someone who understands both the Microsoft platform and the regulatory expectations your institution operates under.

ABT manages your Microsoft 365 tenant and governs the AI tools running inside it. We are a Tier-1 Microsoft Cloud Solution Provider with direct delegated admin access to your tenant, not a reseller who hands you a license and moves on. We have run this configuration for institutions regulated by NCUA, OCC, FDIC, and FFIEC. The playbook exists. We can run it for you before your next examination.

Frequently Asked Questions