How Should a Community Bank Configure Microsoft 365 to Support GLBA Compliance?

The Microsoft 365 Security Controls Community Banks Should Configure

A community bank should configure Microsoft 365 around at least 10 control areas: multifactor authentication, Conditional Access, administrator protection, email security, device management, data-loss prevention, encryption, audit logging, retention and incident response.

Microsoft 365 can support a bank’s obligations to protect customer information, but purchasing a license does not make the environment compliant. The bank must select appropriate licensing, configure the available controls, monitor security events, document its decisions and verify that safeguards continue to work.

For a 25–50 employee community bank, the most urgent priorities are usually to require strong authentication, eliminate legacy access, reduce administrative privileges, secure email, control external sharing, protect managed devices, preserve useful logs and establish a tested response process for compromised accounts.

Does Microsoft 365 Make a Bank GLBA Compliant?

No technology platform can make a community bank compliant by itself. The Gramm-Leach-Bliley Act and related banking-agency information-security standards require financial institutions to maintain administrative, technical and physical safeguards appropriate to their risks.

Microsoft 365 can provide technical capabilities that support those safeguards, including:

• Identity and access management
• Multifactor authentication
• Conditional Access
• Email threat protection
• Device security and management
• Encryption
• Data-loss prevention
• Audit logging
• Information retention
• Security alerting and investigation

The bank remains responsible for determining which controls are necessary, configuring them correctly, reviewing their effectiveness and maintaining evidence of oversight.

The Federal Trade Commission’s Safeguards Rule applies specifically to financial institutions under FTC jurisdiction, which generally means non-bank financial institutions. Banks are typically supervised under information-security standards issued by their applicable banking regulators. Community banks should confirm their specific obligations with legal counsel, compliance professionals and their primary regulator.

The 10-Part Microsoft 365 Security Framework for Community Banks

1. Require Multifactor Authentication

Multifactor authentication, commonly called MFA, requires a user to provide more than a password before accessing an account. It is one of the most important protections against stolen credentials, password reuse and phishing.

A community bank should evaluate MFA for:

• Every employee account
• Every administrator account
• Remote access
• Microsoft 365 applications
• Cloud administration portals
• Third-party users with access to bank resources
• Service accounts where modern authentication is supported

Administrative accounts should use the strongest practical authentication methods. Phishing-resistant options such as security keys, passkeys or certificate-based authentication provide stronger protection than text-message codes.

Avoid Common MFA Gaps

• Do not protect only remote employees.
• Do not exclude executives because MFA is inconvenient.
• Do not rely on security questions as a second factor.
• Do not leave emergency accounts undocumented or unmonitored.
• Do not assume that enabling MFA for some applications protects every sign-in path.
• Do not allow users to approve unexpected prompts without reporting them.

The bank should periodically review Microsoft Entra sign-in information to confirm that MFA is being required as intended and to identify accounts relying on weaker methods.

2. Use Conditional Access to Enforce Risk-Based Rules

Conditional Access uses information about the user, device, location, application and sign-in risk to determine whether access should be allowed, blocked or subjected to additional requirements.

A practical Conditional Access baseline may include policies that:

• Require MFA for all users
• Require stronger authentication for administrators
• Block legacy authentication
• Block access from prohibited countries or regions
• Require compliant devices for sensitive applications
• Restrict unmanaged-device downloads
• Require reauthentication for higher-risk activity
• Block or challenge risky sign-ins
• Protect security-information registration

New policies should normally be evaluated in report-only mode before enforcement. This allows the bank to identify unintended effects, such as blocking a critical application or legitimate third-party process.

Maintain Emergency Access Carefully

The bank may maintain a limited number of emergency administrative accounts to prevent total lockout. These accounts should:

• Use unique, highly protected credentials
• Not be used for routine administration
• Be excluded only from policies that would prevent emergency access
• Generate immediate alerts when used
• Be reviewed and tested on a documented schedule
• Have credentials stored securely with controlled access

3. Protect Privileged and Administrative Accounts

Administrator accounts can change security controls, access data, create users and disable protections. A compromised administrator can therefore create significantly more damage than a compromised standard user.

A bank should:

• Separate routine user accounts from administrative accounts
• Assign only the permissions required for each role
• Reduce the number of Global Administrators
• Use time-limited or approval-based privileged access where licensing permits
• Require stronger authentication for administrative actions
• Alert on new administrators and privilege changes
• Review privileged accounts at least quarterly
• Remove unnecessary roles immediately
• Protect administrative workstations from routine browsing and email use

A Five-Step Privileged Access Review

1. Export every account with an administrative role.
2. Identify the business purpose and owner of each account.
3. Confirm that each assigned role is still required.
4. Remove excessive or inactive privileges.
5. Document the reviewer, date, decisions and completed changes.

Administrative permissions should not remain in place merely because an employee needed them for a project several months ago.

4. Block Legacy Authentication

Older email and application protocols may not support modern authentication controls. Attackers may target these protocols to bypass MFA or exploit weaker sign-in methods.

The bank should identify and address:

• Applications using basic authentication
• Older email clients
• Multifunction printers sending email
• Automated scripts
• Legacy mobile applications
• Third-party systems connecting to Microsoft 365

Legacy authentication should generally be blocked after the bank verifies that critical systems have been updated or replaced. Exceptions should be narrowly scoped, documented, approved and monitored.

5. Strengthen Email Security Against Phishing and Fraud

Email is one of the most common entry points for account compromise, malware and payment fraud. Community banks should apply multiple layers of protection to both incoming and outgoing messages.

Recommended Email Controls

• Advanced spam and phishing filtering
• Malicious attachment scanning
• Time-of-click link analysis
• Executive and domain impersonation protection
• External-sender identification
• Automatic investigation and response where supported
• Mailbox forwarding restrictions
• Alerts for suspicious inbox rules
• Protection against mass message deletion
• Procedures for reporting suspicious email

Configure Domain Authentication

The bank should configure and maintain:

• SPF: Identifies servers authorized to send email for the bank’s domain.
• DKIM: Applies a cryptographic signature that helps recipients verify a message.
• DMARC: Establishes how receiving systems should handle messages that fail authentication and provides reporting.

DMARC should be implemented through a planned process. Moving immediately to a restrictive policy without identifying legitimate senders may disrupt payroll, marketing, statement delivery or vendor communications.

Protect Financial Transactions With Process Controls

Email security tools cannot independently confirm that a payment request is legitimate. Banks should use documented procedures such as:

• Out-of-band verification of wire and payment changes
• Dual approval for sensitive transactions
• Known contact information rather than details supplied in the request
• Escalation for urgent or unusual requests
• Employee training using financial-services scenarios

911 IT’s cybersecurity services combine email protection, endpoint security, firewall management, monitoring and employee training to provide layered protection.

6. Manage Devices and Application Access

A secure Microsoft 365 environment should evaluate both the user and the device requesting access. A valid password and MFA response do not prove that a computer is patched, encrypted or free from malware.

Device-management controls may include:

• Enrollment of bank-owned computers and mobile devices
• Required disk encryption
• Supported operating-system versions
• Endpoint protection status
• Screen-lock requirements
• Minimum password or PIN standards
• Automated patching
• Mobile application protection
• Remote lock or wipe capabilities
• Restrictions on rooted or jailbroken devices

Bank-Owned Devices

Bank-owned systems should generally be managed according to a documented security baseline. The bank should be able to identify:

• The assigned employee
• The device’s configuration and patch status
• Whether encryption is enabled
• Which security tools are active
• Whether the device remains compliant

Personal and Unmanaged Devices

When employees access Microsoft 365 from personal or unmanaged devices, the bank may restrict downloads, require approved applications or permit browser-only access. The correct policy depends on the institution’s risk assessment and business requirements.

Unmanaged-device exceptions should not be created informally. Each exception should have a business justification, approved owner, expiration date and compensating controls.

7. Control Data Sharing and Prevent Unintended Disclosure

Microsoft Teams, SharePoint and OneDrive make collaboration easier, but permissive sharing can expose sensitive information to unintended recipients.

External Sharing Controls

• Limit external sharing to approved business needs
• Restrict anonymous links
• Set expiration dates for guest access
• Require authentication for sensitive resources
• Review external users regularly
• Assign owners to shared sites and teams
• Remove abandoned collaboration spaces
• Alert on unusual sharing activity

The bank should know which sites permit external sharing, who can invite guests and how guest access is removed when a project ends.

Use Sensitivity Labels

Sensitivity labels can help classify and protect information such as:

• Public
• Internal
• Confidential
• Restricted customer information

Depending on the bank’s configuration and licensing, labels may apply visual markings, encryption, sharing limitations or access restrictions.

Use Data-Loss Prevention Policies

Data-loss prevention, or DLP, policies can identify sensitive information and apply controls when employees attempt to share it through email, Teams, SharePoint or OneDrive.

A DLP program may detect:

• Account numbers
• Tax identification numbers
• Social Security numbers
• Payment-card information
• Other customer or employee records

DLP should be introduced carefully. Begin by monitoring activity, measure false positives, train employees and then increase enforcement according to risk. A poorly designed rule can either miss important data or interrupt legitimate work.

8. Use Encryption Without Assuming It Solves Every Risk

Microsoft 365 provides encryption for data in transit and at rest within its services. Additional controls may be used to protect particularly sensitive messages and documents.

The bank should consider:

• Encrypted email for sensitive external communications
• Sensitivity labels that restrict document access
• Managed encryption keys where justified by risk
• Encryption of bank-owned laptops and portable devices
• Secure transfer methods for large or sensitive files
• Policies prohibiting customer information in unapproved applications

Encryption does not prevent an authorized but compromised user from viewing data. It must be combined with identity security, device controls, monitoring and access reviews.

9. Configure Audit Logging, Monitoring and Alerting

A community bank must be able to investigate suspicious activity. Useful logs may show who signed in, what was accessed, which administrative changes occurred and whether information was shared or deleted.

Events the Bank Should Monitor

• Risky or unusual sign-ins
• Repeated authentication failures
• Changes to MFA methods
• New administrative roles
• Conditional Access changes
• New inbox and forwarding rules
• Unusual message deletion
• Mass file downloads
• External sharing changes
• Security tools being disabled
• Audit settings being changed
• Emergency accounts being used

Confirm Log Retention

Microsoft’s default retention periods vary by log type, subscription and licensing. The bank should not assume that every event will remain available for the period required by its risk, investigation, legal or regulatory needs.

Document:

• Which logs are enabled
• How long each log type is retained
• Whether logs are exported to another platform
• Who can search and export them
• Who reviews critical alerts
• How failed log collection is detected

911 IT can integrate cloud events into broader monitoring through its managed cybersecurity and 24/7 threat-monitoring services.

Monitoring Must Lead to Action

An alert is useful only when someone investigates it. The bank should define:

• Which events are critical
• Who reviews alerts during business hours
• Who reviews alerts after hours
• How quickly investigation begins
• Who may disable an account
• When management is contacted
• How the response is documented

10. Establish Retention, Backup and Recovery Procedures

Retention and backup serve different purposes. Retention policies help preserve information according to business, legal and regulatory requirements. Backup provides an additional recovery capability after deletion, corruption, attack or administrative error.

Retention Planning

The bank should define retention requirements for:

• Email
• Teams messages
• SharePoint documents
• OneDrive files
• Audit records
• Former employee data
• Legal holds

Retention periods should be approved by legal, compliance and records-management personnel. An IT provider should configure the technology according to those approved requirements rather than independently deciding how long bank records must be kept.

Microsoft 365 Backup

The bank should determine whether a separate Microsoft 365 backup service is appropriate. A backup strategy may provide:

• Independent copies of cloud data
• Longer or more flexible restoration options
• Protection against accidental deletion
• Recovery after malicious account activity
• Centralized restoration across users and services

The provider should test restoration of email, OneDrive, SharePoint and other protected data. A successful backup status alone does not prove that information can be recovered accurately.

Learn more about 911 IT’s business continuity and backup services.

Which Microsoft 365 License Does a Community Bank Need?

The correct license depends on the controls, users and applications required by the bank. Lower-cost subscriptions may provide email and productivity applications without the advanced identity, device, data-protection and investigation capabilities needed for a stronger financial-services security program.

When comparing licenses, evaluate whether the plan provides the required capabilities for:

• Conditional Access
• Advanced identity protection
• Privileged access management
• Device enrollment and compliance
• Endpoint detection and response
• Advanced email threat protection
• Data-loss prevention
• Sensitivity labels
• Audit and investigation
• Retention and legal hold

Do not select a license solely by comparing the per-user price. The bank should first define its required controls and then determine which subscription or combination of licenses supports those requirements.

Avoid License and Configuration Drift

Over time, banks may accumulate different subscriptions, add-ons and exceptions. A recurring license review should identify:

• Unlicensed active users
• Former employees still consuming licenses
• Users assigned features they do not need
• Employees missing required security capabilities
• Duplicate third-party products
• Upcoming renewal and pricing changes

911 IT’s cloud services include Microsoft 365 integration, administration, security and 24/7 support.

The Microsoft 365 Evidence Examiners and Auditors May Request

A community bank should maintain evidence showing how its Microsoft 365 controls are designed, implemented and reviewed.

Useful evidence may include:

• A current list of licensed users
• An inventory of administrative accounts
• Multifactor authentication coverage
• Conditional Access policy documentation
• Legacy authentication status
• Administrative-role review records
• Device-compliance reports
• Email-security configuration summaries
• External sharing and guest-user reviews
• Data-loss prevention policies
• Retention policy documentation
• Audit and sign-in log retention settings
• Recent security incidents and corrective actions
• Backup and restoration-test results
• Approved exceptions and risk acceptances

Configuration screenshots can support the evidence package, but they should not be the only proof. Reports, review records, tickets and test results help demonstrate that the controls operate over time.

A 30-Day Microsoft 365 Security Improvement Plan

Days 1–7: Assess the Environment

• Inventory users, administrators, guests and licenses
• Review MFA coverage
• Identify legacy authentication
• Export Conditional Access policies
• Review external sharing
• Confirm audit and sign-in logging
• Identify unsupported applications and devices

Days 8–14: Correct High-Risk Identity Gaps

• Require MFA for all users
• Strengthen authentication for administrators
• Remove unnecessary privileged roles
• Disable inactive and former employee accounts
• Block legacy authentication after validation
• Secure and monitor emergency accounts

Days 15–21: Protect Email, Devices and Data

• Strengthen anti-phishing policies
• Configure SPF, DKIM and DMARC
• Review mailbox forwarding
• Establish device-compliance requirements
• Restrict unmanaged-device access
• Review anonymous and external sharing
• Test initial data-loss prevention policies

Days 22–30: Test Monitoring and Recovery

• Simulate a compromised account
• Test after-hours escalation
• Verify that critical events appear in monitoring tools
• Confirm log-retention periods
• Restore a representative mailbox or document
• Document open gaps and assigned owners
• Present a prioritized roadmap to management

A Compromised Microsoft 365 Account Response Framework

The bank should maintain a documented process for suspected account compromise.

1. Contain: Disable the account or block sign-in when appropriate.
2. Revoke: Terminate active sessions and tokens.
3. Secure: Reset credentials and re-register authentication methods.
4. Investigate: Review sign-ins, mailbox rules, messages, file access and administrative changes.
5. Remove: Delete malicious rules, applications or unauthorized permissions.
6. Assess: Determine whether customer information or financial activity was affected.
7. Escalate: Involve management, legal counsel, insurance and regulatory personnel as required.
8. Recover: Restore access after the account and associated devices are considered safe.
9. Improve: Document the root cause and implement corrective controls.

The response plan should address both the cloud account and the employee’s device. Resetting a password will not solve the problem when malware or a malicious browser session remains active.

Common Microsoft 365 Security Mistakes

• Assuming every user has MFA because administrators do
• Using the same account for email and administration
• Leaving former employees and contractors active
• Allowing legacy authentication indefinitely
• Failing to review mailbox forwarding rules
• Giving too many users Global Administrator access
• Allowing anonymous sharing by default
• Ignoring guest accounts after a project ends
• Relying only on Microsoft’s default retention
• Failing to back up cloud information
• Collecting alerts without assigning someone to investigate them
• Implementing Conditional Access without testing
• Purchasing security licenses without configuring the included controls
• Failing to document exceptions

Questions to Ask a Microsoft 365 IT Provider

1. Which Microsoft 365 security controls are included in our service?
2. Which required capabilities depend on additional licensing?
3. How do you verify MFA coverage?
4. Who designs and approves Conditional Access policies?
5. How do you protect administrator accounts?
6. Who reviews Microsoft 365 alerts after hours?
7. How quickly can you disable a compromised user?
8. How long are our sign-in and audit logs retained?
9. Do you monitor for forwarding rules and suspicious sharing?
10. How do you manage employee onboarding and termination?
11. Are Microsoft 365 email and files backed up?
12. How often do you test restoration?
13. What compliance evidence will we receive?
14. How are configuration changes documented?
15. What happens to our documentation if we change providers?

What Financial Organizations Value in Microsoft 365 Support

911 IT’s financial-industry clients consistently emphasize the importance of fast response, proactive recommendations, strong security and technicians who already understand their environment.

One financial-services client credited 911 IT with helping implement and maintain network safeguards associated with strict IRS and PCI security requirements. The client valued having a dedicated team that understood the firm’s systems and could respond without requiring the entire environment to be explained during every request.

Another financial client described working with 911 IT as having an entire IT department available without the expense of hiring an equivalent internal team. That client also valued recommendations informed by 911 IT’s experience supporting other financial organizations.

A separate long-term client reported that 911 IT responds promptly, takes ownership of requests and verifies that problems are fully resolved before closing them. That level of follow-through is especially important when cloud security depends on dozens of connected settings rather than one product.

Learn more about 911 IT’s experience providing IT support for CPAs and financial firms.

Frequently Asked Questions

Is Microsoft 365 secure enough for a community bank?

Microsoft 365 provides security capabilities that can support a community bank, but the environment must be licensed, configured, monitored and maintained according to the institution’s risk assessment. Default settings alone may not provide the controls the bank requires.

Does every bank employee need multifactor authentication?

Community banks should strongly evaluate MFA for every employee, administrator and third party accessing Microsoft 365. Accounts without MFA can provide attackers with an easier path into email, documents and other connected resources.

Is text-message MFA sufficient?

Text-message verification is generally stronger than a password alone, but more resistant methods are preferable for administrators and other high-risk users. The bank should select authentication methods based on its risk assessment and available technology.

What is Conditional Access?

Conditional Access is Microsoft’s policy engine for making access decisions based on factors such as user identity, device compliance, location, application and sign-in risk. It can require MFA, restrict access or block a sign-in.

Does Microsoft back up Microsoft 365 data?

Microsoft operates resilient infrastructure and provides retention and recovery capabilities, but those capabilities may not meet every bank’s restoration and retention requirements. The institution should evaluate whether a separate backup service is needed.

How often should administrative access be reviewed?

Privileged access should be monitored continuously and formally reviewed on a recurring schedule. A quarterly review is a practical starting point for many smaller institutions, with immediate review after personnel or role changes.

How often should external users be reviewed?

Guest and external access should be reviewed regularly and removed when the business purpose ends. Higher-risk collaboration spaces may require more frequent review.

Can an MSP guarantee GLBA compliance?

No. An MSP can configure safeguards, monitor systems, produce reports and help correct technical weaknesses. The bank retains responsibility for governance, risk management, oversight and determining which requirements apply.

What should happen when an employee leaves?

The bank should promptly block access, revoke sessions, remove authentication methods, preserve required information, transfer ownership of business data and recover bank-owned devices. The completed steps should be documented.

Secure Microsoft 365 as a Financial System, Not Just an Email Platform

Microsoft 365 contains employee identities, internal communications, customer information and access to connected business systems. Community banks should manage it as a critical financial-services platform rather than a basic email subscription.

911 IT provides Microsoft 365 management, managed IT, cybersecurity and business-continuity services for organizations in Salt Lake City and throughout Utah. Our team combines local engineering resources, live 24/7 support, cloud administration and continuous security monitoring under one accountable relationship.

Schedule a 10-minute discovery call to review your bank’s Microsoft 365 licensing, authentication, administrator security, data sharing and monitoring coverage. You can also contact 911 IT to request a Microsoft 365 security assessment.

This article provides general educational information and is not legal, regulatory or compliance advice. Financial institutions should consult their primary regulator, legal counsel and qualified compliance professionals regarding requirements that apply to their circumstances.