Microsoft 365 Security Audit Checklist for Community Banks

Your community bank runs on Microsoft 365. Email, file sharing, Teams calls with loan officers, compliance documents stored in SharePoint. But when was the last time anyone audited the security configuration behind all of it? For most community banks, the answer is uncomfortable: the tenant was set up years ago, and nobody has done a systematic review since. That gap is exactly what examiners and attackers are looking for.

This checklist covers 30+ configuration checks across identity, data protection, threat defense, and compliance. It is built from real audit findings across hundreds of community bank M365 tenants, organized so your IT team (or your managed service provider) can work through it methodically before your next OCC or FDIC examination.

In This Article

• Why Community Banks Need a Microsoft 365 Security Audit
• Identity and Access Management Audit (10 Checks)
• Data Protection Audit (8 Checks)
• Threat Protection Audit (7 Checks)
• Compliance and Governance Audit (5 Checks)
• From Audit to Action: Prioritizing Remediation
• Frequently Asked Questions

Why Community Banks Need a Microsoft 365 Security Audit

Most community banks treat Microsoft 365 as "just email." In reality, your M365 tenant holds the majority of your institution's sensitive data: customer financial records, internal communications, board documents, loan files, and compliance reports. It is the single largest attack surface in your technology stack.

Examiners know this. The OCC's Bulletin 2025-3 on digitalization for community banks specifically addresses cloud computing risks. The FDIC Office of Inspector General published AUD-25-02 in September 2025, an audit of cloud platform security controls that found specific deficiencies in access management and configuration monitoring. These aren't hypothetical risks. Regulators are actively examining cloud configurations.

The gap between what examiners expect and what most community banks actually have configured is significant. A systematic security audit closes that gap before the examiner finds it for you.

Identity and Access Management Audit (10 Checks)

Identity is the new perimeter. Every M365 breach starts with a compromised credential. These ten checks verify that your bank's identity controls match what examiners and attackers both look for.

1. MFA Enforcement Across All Accounts

Verify that multi-factor authentication is enforced for every user account, including service accounts, shared mailboxes with sign-in enabled, and all administrator roles. No exceptions. Legacy per-user MFA settings should be migrated to Conditional Access-based MFA for centralized policy management.

2. Conditional Access Policies for Compliant Devices

Confirm that Conditional Access policies require device compliance before granting access to Exchange Online, SharePoint, and Teams. A policy that only requires MFA but allows access from any unmanaged device still leaves your data exposed.

3. Legacy Authentication Blocked

Legacy authentication protocols (POP3, IMAP, SMTP AUTH, ActiveSync basic auth) bypass MFA entirely. Microsoft formally deprecated these protocols, but many community bank tenants still have them enabled for older applications. Create a Conditional Access policy that blocks legacy authentication for all users. Check sign-in logs first to identify any applications still relying on these protocols.

4. Privileged Role Management

Review all users assigned to Global Administrator, Exchange Administrator, SharePoint Administrator, and Security Administrator roles. The principle of least privilege applies: no user should hold a permanent admin role if Privileged Identity Management (PIM) is available. With PIM, administrators activate their elevated role only when needed, with time-limited access and approval workflows.

5. Sign-In Risk Policies

Enable sign-in risk policies that require MFA or block access when Microsoft Entra ID Protection detects anomalies: sign-ins from unfamiliar locations, impossible travel patterns, or known malicious IP addresses. These policies are included with Entra ID P2 licensing (part of M365 E5 or available as an add-on).

6. Break-Glass Emergency Accounts

Maintain at least two emergency access accounts that are excluded from Conditional Access policies. These accounts should use long, complex passwords stored securely (not in a shared spreadsheet), have no MFA requirement (by design, for emergency lockout scenarios), and be monitored with alerts for any sign-in activity.

7. Guest Access Controls

Review external guest accounts in your Entra ID directory. Remove stale guests (no sign-in in 90+ days). Restrict which domains can be invited. Limit guest access to specific Teams and SharePoint sites rather than granting broad directory access.

8. Service Principal and App Registration Hygiene

Audit all registered applications and service principals. This is where the February 2026 OAuth token theft attacks hit: malicious OAuth apps granted excessive permissions. Remove any app registrations that IT cannot identify. Review consent grants and revoke any with overly broad permissions (Mail.ReadWrite, Files.ReadWrite.All, etc.).

9. Password Policies

With MFA enforced, NIST 800-63B guidance recommends longer passwords (12+ characters minimum) without forced periodic rotation. Implement banned password lists that include your bank's name, common financial terms, and locally relevant words. Enable password protection in Entra ID to block commonly compromised passwords.

10. Session Management

Configure session timeouts appropriate for banking. Persistent browser sessions should be disabled for users accessing customer financial data. Sign-in frequency policies should require reauthentication at least every 12 hours for standard users and every 4 hours for administrators.

The 30-Point M365 Security Audit Checklist: four quadrants covering every critical configuration.

Data Protection Audit (8 Checks)

Identity controls determine who gets in. Data protection controls determine what they can do once they're there. For community banks handling GLBA-regulated customer information, these checks verify that your data classification and loss prevention controls are actually working.

11. DLP Policies for Financial Data

Verify that Data Loss Prevention policies are configured to detect and block sensitive financial data: Social Security numbers, account numbers, routing numbers, and tax identification numbers. DLP should cover Exchange Online, SharePoint, OneDrive, and Teams. Test your policies by sending a test message with dummy SSN-formatted data to confirm they fire correctly.

12. Sensitivity Labels for GLBA-Classified Data

If your bank uses Microsoft 365 E3 or E5, implement sensitivity labels that classify documents by their GLBA data classification level. At minimum, create labels for Public, Internal, Confidential (customer PII), and Restricted (board/executive). Labels should enforce encryption on Confidential and Restricted content automatically.

13. External Sharing Restrictions

SharePoint and OneDrive external sharing should be restricted to specific domains (approved vendors, auditors, regulators) or disabled entirely. Check the tenant-level sharing settings and each site's individual override. Many community banks have tenant-level restrictions but individual sites configured to allow anonymous sharing.

14. Teams and SharePoint Access Controls

Review Teams and SharePoint permissions. Look for: Teams channels shared with external users, SharePoint sites with "Everyone" or "Everyone except external users" permissions, and channels containing customer financial data that lack appropriate access restrictions.

15. Email Encryption (Office Message Encryption)

Confirm that mail flow rules automatically encrypt outbound messages containing sensitive data patterns (SSNs, account numbers). Verify that users also have the option to manually encrypt messages via the Encrypt button in Outlook. Test both the automatic rules and manual encryption to confirm recipients can actually decrypt the messages.

16. Attachment and Link Policies

Configure Safe Attachments to block malicious attachments before they reach user inboxes. Enable Safe Links to rewrite URLs and check them at time of click. Both features require Defender for Office 365 (included in M365 Business Premium and E5).

17. Link Sharing Defaults

The default sharing link type in SharePoint and OneDrive should be "Specific people" (not "Anyone with the link" or "People in your organization"). Check this setting at both the tenant level and site level. A permissive default creates accidental data exposure when users share documents without thinking about the audience.

18. Mobile Device Data Wipe

Verify that your Intune mobile device management policies include the ability to remotely wipe corporate data from lost or stolen devices. This should be a selective wipe (corporate data only) rather than a full device wipe, especially for BYOD scenarios. Test the wipe process on a test device to confirm it works as expected.

Threat Protection Audit (7 Checks)

Data protection is passive defense. Threat protection is active. These checks verify that your M365 tenant is configured to detect, block, and respond to the specific attack patterns targeting financial institutions.

19. Defender for Office 365 Configuration

Verify that Safe Links and Safe Attachments are enabled with the recommended Microsoft settings. Safe Links should use real-time URL scanning, not just a known-bad list. Safe Attachments should use the "Dynamic Delivery" option so users get the email body immediately while attachments are scanned in a sandbox.

20. Anti-Phishing Policies

Configure anti-phishing policies in Defender for Office 365 to detect impersonation of your bank's executives, board members, and key vendors. Enable mailbox intelligence to learn each user's communication patterns and flag anomalies. Set the impersonation protection to quarantine suspicious messages rather than just adding a safety tip.

21. Automated Investigation and Remediation (AIR)

If you have Defender for Office 365 Plan 2, enable automated investigation and remediation. When a user reports a phishing email or an automated detection fires, AIR automatically investigates the scope (did other users receive the same email?), correlates related signals, and can auto-remediate by purging malicious messages from all mailboxes.

22. Alert Policies

Review the default alert policies in the Microsoft Purview compliance portal. At minimum, ensure alerts are active for: malware detected in email, unusual external file sharing activity, creation of forwarding or redirect rules (a common BEC tactic), and new admin role assignments. Route alerts to your security team or MSP, not to a generic mailbox nobody monitors.

23. Unified Audit Log Retention

The default audit log retention in M365 is 180 days. For community banks, FFIEC examination requirements typically expect at least one year of log retention. If you're on an E5 or E5 Compliance add-on license, enable 10-year audit log retention for critical activities. If you're on a lower license tier, integrate M365 audit logs with a SIEM or log management platform that provides the required retention period.

24. SIEM Integration

For banks with in-house security operations or an MSP partner providing monitoring, verify that M365 audit logs and Defender alerts are flowing into your SIEM platform. Microsoft Sentinel is the native option and integrates directly. Third-party SIEMs (Splunk, Elastic, etc.) can ingest M365 data via the Management Activity API or diagnostic settings.

25. Tenant Allow/Block Lists

Review the Tenant Allow/Block List in Microsoft 365 Defender. Check for overly broad allow entries (entire domains that bypass filtering) and ensure block entries are current. Examiners will ask why specific senders or domains were whitelisted, so document the business justification for every allow entry.

Risk Prioritization Matrix: where your M365 misconfigurations fall on the impact-likelihood spectrum.

Compliance and Governance Audit (5 Checks)

Security controls protect data in real time. Compliance and governance controls prove to examiners that your protections are systematic, documented, and auditable. For community banks subject to GLBA, FFIEC, and OCC/FDIC oversight, these checks verify that your M365 tenant supports your compliance obligations.

26. Retention Policies for Regulatory Requirements

Configure Microsoft Purview retention policies that match your record retention schedule. Email retention for banking typically requires 5-7 years depending on the content type and state requirements. Apply retention labels to Teams chat messages, SharePoint documents, and OneDrive content. Verify that retention policies are actually being applied (check the policy status in the Purview compliance portal).

27. eDiscovery Readiness

Confirm that eDiscovery permissions are assigned to the appropriate compliance or legal staff. Run a test search to verify that content across Exchange, SharePoint, OneDrive, and Teams is discoverable. If your bank has experienced a regulatory inquiry in the last year, verify that the relevant content holds are still in place and haven't been accidentally released.

28. Communication Compliance

For banks concerned about insider risk, configure communication compliance policies in Microsoft Purview to flag potentially inappropriate communications: mentions of specific account numbers outside normal business context, references to undisclosed conflicts of interest, or language patterns associated with fraud. This feature scans Exchange, Teams, and third-party connectors.

29. Information Barriers

If your community bank has separate business units that regulatory requirements mandate be isolated (commercial lending and personal banking, for instance), implement information barriers in M365 to prevent users in one segment from communicating with or accessing documents from the other segment.

30. Compliance Manager Score

Review your Compliance Manager score in the Microsoft Purview compliance portal. Compliance Manager provides pre-built assessments for FFIEC, GLBA, and other regulatory frameworks. Your score represents the percentage of recommended improvement actions you've completed. Document this score and track it over time. Examiners want to see a trajectory, not just a snapshot.

From Audit to Action: Prioritizing Remediation

Completing the audit produces a list of gaps. The next step is scoring each gap by risk and building a remediation timeline that your team can actually execute.

Risk Scoring Framework

Score each audit finding on two dimensions: likelihood of exploitation and impact if exploited.

• Critical (fix within 7 days): No MFA on admin accounts, legacy authentication enabled, no DLP policies, overly broad OAuth app permissions
• High (fix within 30 days): Missing Conditional Access policies, no Safe Attachments/Safe Links, audit log retention below regulatory minimum, no sensitivity labels
• Medium (fix within 60 days): Guest access not reviewed, session timeout policies not configured, Compliance Manager assessment not completed, eDiscovery not tested
• Low (fix within 90 days): Password policy refinement, information barriers (if applicable), communication compliance tuning

Typical Remediation Timeline

For a community bank starting from a largely default M365 configuration, a realistic remediation timeline looks like this:

• Week 1-2: Address all Critical items. Enable MFA everywhere. Block legacy authentication. Deploy baseline DLP policies. Revoke suspicious OAuth app permissions.
• Week 3-4: Address High items. Build Conditional Access policies. Enable Defender for Office 365 protections. Extend audit log retention.
• Month 2: Address Medium items. Review guest access. Configure session policies. Complete Compliance Manager assessments.
• Month 3: Address Low items and fine-tune all policies based on the first 60 days of monitoring data.

Preventing Configuration Drift

The hardest part of an M365 security audit isn't the initial remediation. It's preventing the configuration from drifting back. Changes to Conditional Access policies, new admin role assignments, modified sharing settings, and newly registered applications can undo your hardening work within weeks.

This is where continuous monitoring matters. Managed M365 services that include ongoing configuration monitoring detect drift as it happens, not when the next audit reveals it. ABT's Guardian monitoring layer checks tenant configuration continuously and alerts on any deviation from your hardened baseline.

Frequently Asked Questions