Microsoft 365 Data Retention for Financial Institutions

A loan officer leaves your credit union. Six months later an examiner asks for every email tied to a denied application she handled. Your IT team starts digging and finds the mailbox was deleted ninety days after she left, the Teams chats are gone, and the SharePoint folder was cleaned up during an offboarding script. That is the moment most financial institutions discover their Microsoft 365 retention was never actually configured for the records they are legally required to keep.

Microsoft 365 ships with general-business defaults. Deleted mailboxes purge after thirty days. Teams chat retention is short. SharePoint version history is finite. None of that was designed for a bank, credit union, or mortgage company that has to produce five-year-old wire records on demand or a Closing Disclosure from four years back. The data piles up, mailboxes balloon past quota, and the one time you need a specific message it is the one thing that already aged out.

This guide walks through how data retention and email archiving actually work in Microsoft 365 through Microsoft Purview, why retention is a different job than backup and a different job than data loss prevention, how long the major federal rules require you to keep records, and how a Tier-1 Microsoft Cloud Solution Provider configures the whole thing so it holds up when an examiner comes knocking.

Why does Microsoft 365 data retention matter for financial institutions?

Retention matters because the default Microsoft 365 configuration deletes content on a schedule that has nothing to do with your regulatory obligations. A credit union under NCUA oversight, a community bank examined against the FFIEC handbook, and a mortgage company answering to the CFPB all share the same problem: the records examiners want often outlive the platform's out-of-the-box behavior, and finding them after the fact is slow, manual, and sometimes impossible. Across the 750+ financial institutions ABT manages, the gap is rarely awareness that records matter. It is the in-house Microsoft Purview and regulatory fluency to translate a patchwork of federal recordkeeping rules into retention policies that actually hold up under examination.

Two operational pressures show up first, well before anyone mentions an exam. The first is storage sprawl. Mailboxes hit quota, users start deleting to make room, and the deletions are exactly the messages that should have been preserved. Microsoft Purview Data Lifecycle Management solves this by retaining content on a policy you define across Exchange email, SharePoint, OneDrive, Teams chats and channel messages, and Microsoft 365 Groups, so the data is kept on purpose rather than deleted by accident.

The second pressure is response time. When a regulator, an auditor, or opposing counsel asks for records, the question is never "do you have a backup somewhere." The question is "can you find and produce the specific communications that matter, in a defensible format, quickly." A tenant with no retention policies and no holds turns that request into a forensic project. A tenant configured correctly turns it into a search. The same discipline that keeps your data from disappearing is what lets you find it again, and both start with Microsoft Purview.

This is also where the operational story connects to compliance. The retention controls that protect your productivity from accidental deletion are the same controls examiners expect to see governing your recordkeeping. Get the configuration right once and you serve both goals at the same time. For the broader picture of how these pieces fit together, our complete guide to Microsoft 365 for financial institutions maps the full governance stack.

What is the difference between retention, backup, and DLP in Microsoft 365?

Retention, backup, and data loss prevention are three distinct jobs, and conflating them is the most common mistake we see. Retention preserves and deletes content on a schedule for compliance. Backup creates point-in-time copies so you can restore after data loss or corruption. Data loss prevention stops sensitive data from leaving the environment in the first place. One does not substitute for another.

Microsoft 365 operates on a shared-responsibility model. Microsoft documents that you own your data and you are responsible for protecting it. Microsoft Purview retention policies and holds are governance and eDiscovery controls. They keep content from being purged and make it discoverable, but they are not a customer-controlled point-in-time restore. That recovery objective is a separate problem, which is why Microsoft sells a distinct Microsoft 365 Backup product for fast restore. Retention is not a backup, and a backup is not retention. You may want both, for different reasons.

Drawing the lines this way is not pedantry. It changes what you buy and how you configure it. An institution that thinks its retention policy is a backup will be surprised when ransomware encrypts live SharePoint and there is no clean restore point, because retention preserved the encrypted version too. An institution that thinks its backup satisfies a five-year recordkeeping rule will struggle to produce a defensible, searchable record set during an exam. We unpack the recovery side in our look at Microsoft 365 backup for financial institutions, and the prevention side in how DLP works for financial services.

Source: Microsoft Purview documentation, 2026

How long must banks, credit unions, and mortgage companies keep records?

Retention periods come from the rule that governs the record, not from the platform. There is no single number. BSA/AML records run five years, Regulation Z general records run two years, the TRID mortgage records have their own three-year and five-year rules, Regulation B runs twenty-five months, and the NCUA requires a written preservation program rather than a fixed period. Your retention policy in Microsoft Purview has to mirror that patchwork, not flatten it.

The longest of the common obligations is anti-money-laundering recordkeeping. Under the Bank Secrecy Act regulations, covered financial institutions must keep required records for five years, and that period is corroborated across FinCEN guidance and the FFIEC BSA/AML Examination Manual. It is the floor most institutions design their email and document archiving around.

Mortgage lenders carry an extra layer of nuance that trips up generic IT providers. Regulation Z's general record-retention rule, at 12 CFR 1026.25(a), is two years. The mortgage disclosure retention sits in a separate subsection, 12 CFR 1026.25(c): records evidencing compliance with the TRID disclosures under 1026.19(e) and (f) must be kept three years after consummation, and the Closing Disclosure and related documents must be kept five years. Writing a single "Reg Z = three years" policy gets both pieces wrong. The table below lines up the major federal obligations against the correct citation.

Credit unions face a different shape of requirement. NCUA's 12 CFR Part 749 does not hand you a number. It requires each federally insured credit union to maintain a written records preservation program, identify its vital records, and store duplicates off-site. That program-based approach means a credit union has to document its own retention decisions and show examiners the policy, which is exactly the kind of evidence a configured Purview retention scheme produces. Our walkthrough of what NCUA examiners actually look for covers how this lands in a real exam.

Source: 31 CFR 1010.430; 12 CFR 1026.25; 12 CFR 1002.12(b); 12 CFR Part 749

One practical note on building these policies: longer retention means more stored data, and that is where the archive ceiling matters. An Exchange Online archive mailbox adds up to 100 GB, and auto-expanding archiving then grows incrementally up to a maximum of 1.5 TB per mailbox. That headroom lets an institution hold five-plus years of messages without forcing deletions, provided the mailbox carries a qualifying license. The licensing tier you choose determines which retention, archiving, and eDiscovery features you actually have, which is why we compare them in our breakdown of Microsoft 365 E3 vs E5 vs Business Premium for financial institutions.

How do you make Microsoft 365 records tamper-proof and discoverable?

Tamper-proofing and discovery are two related but separate capabilities. Preservation mechanisms like Litigation Hold and eDiscovery holds keep content from being deleted or altered out of existence while a matter is open. True write-once-read-many immutability, the kind Microsoft documents as aligning with SEC Rule 17a-4(f), comes specifically from a Microsoft Purview retention policy or label with Preservation Lock applied. Knowing which control does which job is what separates a defensible setup from a fragile one.

Litigation Hold preserves all mailbox content, including items a user deleted or modified, for as long as the hold is in place. Microsoft Purview eDiscovery holds extend that preservation across Exchange, SharePoint, OneDrive, and Teams until the hold is removed. These are the right tools when you need to lock down a custodian's data for an investigation or a lawsuit. They are preservation controls, and they are essential, but a hold by itself is not the same thing as a locked, non-rewritable retention regime.

The practical sequence is to use retention policies and labels to define what is kept and for how long, apply Preservation Lock where you need WORM-grade immutability for the record class that demands it, and layer Litigation Hold or eDiscovery holds on top when a specific matter requires you to freeze a custodian's content. Each control has a job. Used together, they give you records that cannot be quietly altered and a search surface that can produce them on request. That combination is also what makes a defensible answer possible during the kind of recordkeeping scrutiny we discuss in our BSA/AML compliance guide for Microsoft 365.

How do you configure examiner-ready retention in Microsoft Purview?

Examiner-ready retention is configured in the Microsoft Purview portal at purview.microsoft.com, which replaced the older Microsoft Purview compliance portal. The work itself is not a single switch. It is a sequence: map your records to the rules that govern them, build a retention label taxonomy, publish policies to the right workloads, apply Preservation Lock where immutability is required, and validate that holds and eDiscovery actually work. Most institutions do not have the in-house time or the regulatory fluency to do all of that correctly, which is where a managed partner earns its place.

This is the part that managed Microsoft 365 changes for a financial institution. ABT manages your Microsoft 365 tenant, which means configuring Purview retention policies, the label taxonomy, Preservation Lock, and eDiscovery holds, and then monitoring them so they do not drift out of compliance as your environment changes. We do not host your Microsoft 365 (Microsoft owns that infrastructure); we manage the tenant, which is exactly the delegated-administration role a Tier-1 Cloud Solution Provider is built for. The same discipline carries into adjacent governance work like Microsoft Purview for AI agents and broader FFIEC IT examination readiness.

Under M365 Guardian, ABT's operating model for Microsoft 365, retention is configured as part of a hardened, monitored tenant rather than a one-time project that quietly rots. The label taxonomy gets built to match your record classes, Preservation Lock goes where immutability is required, and Guardian watches for drift so a future admin change does not silently undo the recordkeeping your examiners rely on. That is the difference between owning a Purview license and actually being examiner-ready.

Frequently Asked Questions